Re: [HACKERS] parse_coerce question

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
>>>> It seems to me that parse_coerce ought to do parse-time coercion if
>>>> the input tree is a constant of either UNKNOWNOID, INT4OID, or FLOAT8OID
>>>> type, and only fall back to inserting a function call if it's unable
>>>> to do the coercion. Am I missing anything?
>> You are right. The textin/out trick is an old one, and one we only did
>> because we _had_ to make some conversion at that point. No problem
>> making it more general.

> Sure, as long as we don't use textin/out to do it. It's an old trick
> with more limitations than benefits. The Right Way to approach it is
> to use type-specific conversion functions, so that real conversions
> can take place.

Right --- the revision I committed last night looks up the
type-conversion function the same as before, but then applies it
immediately if the input is a constant.

> It should be easy to pre-evaluate that function,
> which btw should happen anyway. afaik it does, but not until after the
> optimizer has had its look at the query,

I'm not aware of any post-optimizer place where that might happen.
In any case, the optimizer would be much happier if constant-expression
reduction happened before it rather than after.

> For the index selection problem, I was thinking to move some of the
> parse_coerce techniques to that part of the code, so that functions on
> constants are allowed to be considered as candidate constants in a
> query.

I still think we want a generalized constant-expression folder, applied
after rule rewrite and before the optimizer. This particular case was
just something I thought the parser should handle, since it was already
handling closely related cases...

> In any case, you'll need to make sure that you only promote types one
> direction, so that (for example)
> select intcol from table where intcol < 33.5;
> gets evaluated correctly.

That is not parse_coerce()'s problem --- it just does what it's told.

regards, tom lane