Re: [HACKERS] Re: type coersion (was OR clause status)

Thomas G. Lockhart wrote:
>
> It is inside backend/optimizer/path/indxpath.c. I'm using a bit of the
> parser support code to help out. It has to be where the backend actually
> is checking to see if an index is usable, which is in the optimization
> step. Any earlier and we would have to look-ahead at the indices which
> seems inappropriate.

Just let me note that function calls on constants is problem not
only for indices using. Call lower() for each tuple in
WHERE a = lower('bbb') is always bad - lower() eats memory...

> > I think binary compatable types converted is going to be the easiest
> > thing to do for index use. Not sure how you could try and break it.
> > How about character string comparisons using indexes?

Parser could use type_in()/type_out() funcs to do type
coersion...

>
> Will try some more tests, but it seems like it will be hard to break
> since it only comes into effect with built-in datatypes which are
> supposed to be binary compatible.
>
> It would be interesting to try to do constant expressions and function
> calls on constants next, though I'm thinking that it isn't required for
> v6.4.
>
> Vadim, will the executor know how to use a PARAM_EXEC node in any
> context, or will we have to do some coding to get it recognized outside
> of subselects? I'll need to figure out how to build one too, I
> suppose...

I'm not sure... But imho, PARAM_EXEC could be usefull for
now() etc funcs - for non-variant funcs I would suggest
just evaluate them in parser...

Vadim