Dennis Bjorklund <db@zigo.dhs.org> writes:
> I still think that this is a type inference problem and nothing else.
Well, perhaps ripping out the entire type resolution algorithm and
replacing it with something less ad-hoc is indeed the right long-term
answer. I don't have time to do that though. Do you? It seems like
a fairly large project with possibly zero payback, if we find that too
many behavioral incompatibilities are introduced to make it adoptable.
> Another thing I don't understand is why '42' works but not 42.
Because in the '42' case the determination of the constant's type is
indeed postponed ... though no doubt in a way that's too ad-hoc ;-)
Another thing to keep in mind is that it's not always the case that
assigning the right type to a literal constant would solve the problem.
We have the same issues with variables; for example, a join with
"WHERE a.int8col = b.int4col" may fail to take advantage of available
indexes.
Something else that's been troubling me about the issue is that the most
efficient operator to use is really context-dependent. In the example
of "WHERE a.int8col = b.int4col", we basically have two possible
choices; use a cross-type operator (int8 = int4), or introduce a
coercion, so that the clause becomes "WHERE a.int8col = b.int4col::int8"
using an int8 = int8 operator. The latter is a win when considering
indexscans on the int8 column, and also a win for hash joins (cross-type
operators in general aren't hashable). *But* the former is a win for
merge joins, and particularly for implied equality deduction. If we
force the coercion-based representation to be used then the planner will
be able to deduce that a.int8col and b.int4col::int8 are equal, but it
would have to make a leap of faith to relate that knowledge to the bare
b.int4col column. This would eg. prevent the use of a mergejoin with
use of an index on the int4 column.
So I'm beginning to think that avoiding cross-type operators is not the
right route to a solution anyway. It may be better to leave the parser
alone and teach the planner how to switch to the alternate
representation when and where appropriate. (The connection to hash
joins suggests that tying this closely to index opclasses is wrong,
though.)
regards, tom lane
