> > 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. textin/out relies on the fact that the printed format
of a type is *precisely* the same as the format for the target type,
which is true for only a very limited number of cases.
There is already code for doing type coersion. As Tom points out, it
currently wraps a type conversion function around the constant, to be
evaluated later. 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, and by then it is too late to
select an index properly, for example.
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.
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.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California