Subject | Re: [ib-support] Strange query results, based on where clause |
---|---|
Author | Claudio Valderrama C. |
Post date | 2002-03-07T07:56:56Z |
""Ann W. Harrison"" <aharrison@...> wrote in message
news:5.1.0.14.2.20020306103539.0206c7a8@......
- Pass an additional param to compress, so it will complain on some
conversions when that extra flag is true. This will stop the operation.
(Some callers would have to have the flag passed in turn, I guess.)
- Throw more code in the compiler so when heterogeneous comparisons are
done, index usage is skipped. At least do that for int=string cases.
C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing
news:5.1.0.14.2.20020306103539.0206c7a8@......
> There are problems with making the index code follow theThen I see two solutions:
> precedence order in CVT.
>
> The index isn't used for a comparison, exactly, but for
> a lookup. The values to be matched are coded as if they
> were an index key and that value is retrieved if it
> exists. There's no way to look up something that might
> be '0617', or '617' or '00000617' or might be a double
> precision number representing the value 617.
>
> I think changing the index behavior is a non-starter.
- Pass an additional param to compress, so it will complain on some
conversions when that extra flag is true. This will stop the operation.
(Some callers would have to have the flag passed in turn, I guess.)
- Throw more code in the compiler so when heterogeneous comparisons are
done, index usage is skipped. At least do that for int=string cases.
C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing