> 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...
Sure, so we want to evaluate as a constant. I've found a place in the
code where a function gets evaluated immediately; don't remember where
but it looked like an interesting possibility.
> > > How about character string comparisons using indexes?
> Parser could use type_in()/type_out() funcs to do type
> coersion...
That is what it used to try to do. But I don't think that generalizes
very well. For example, at the moment floating point numbers without
fractional parts are printed without a decimal point or trailing digits,
but we could decide to format them with a ".0" at the end. Then they
couldn't be converted to an integer...
> > 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...
But it could be used for every function called with constants, right? If
it works for everything, why bother with other special cases?
- Tom
