Subject | Re: [firebird-support] NOT IN + sub-select + null value + inner join + index = bug ? |
---|---|
Author | Ann W. Harrison |
Post date | 2005-02-18T18:53:17Z |
olivier_lucaes wrote:
indexes is evidence of a bug. The problem appears to be fixed in
Version 2. More precisely, when I run you definition scripts and
queries I get different answers depending on the existence of index
IDX_TB3 with Firebird 1.03 and Firebird 1.52, but my version of Vulcan,
based on a very early V2 gets the same answer with and without the index.
So, my guess is 1) yes it is a bug. and 2) is fixed with the
improvements in null handling in V2. The fix was not part of the Vulcan
effort ... almost nothing ... maybe nothing at all ... was done to
indexes as part of Vulcan.
Regards,
Ann
>...
> Hello there,
> I not sure if this is really a bug or a logic error from my side. If
> anybody could reproduce...
> [with index on TB3] returns :Any query that returns different results when run with and without
> 2
> 3
> 4
>
>
> when no index is defined for TB3, the same select
> returns :
> 1
> 2
> 3
> 4
> 5
indexes is evidence of a bug. The problem appears to be fixed in
Version 2. More precisely, when I run you definition scripts and
queries I get different answers depending on the existence of index
IDX_TB3 with Firebird 1.03 and Firebird 1.52, but my version of Vulcan,
based on a very early V2 gets the same answer with and without the index.
So, my guess is 1) yes it is a bug. and 2) is fixed with the
improvements in null handling in V2. The fix was not part of the Vulcan
effort ... almost nothing ... maybe nothing at all ... was done to
indexes as part of Vulcan.
Regards,
Ann