Peter Eisentraut <peter_e@gmx.net> writes:
> ... I'm not sure about the terminology "position" and "instance"; they're
> just two coordinates to get at the problem.
> None of this will help if you have multiple unrelated clauses that
> invoke select_common_type(), but that might be better handled using the
> parser location mechanism.
Were there any objections to changing this patch so that it reports
the second expression's parser location, instead of some arbitrary
numbers? The way I'm envisioning doing it is:
1. Invent an exprLocation() function (comparable to, say, exprType)
that knows how to get the parser location from any subtype of Node that
has one.
2. Make a variant of select_common_type() that takes a list of Exprs
instead of just type OIDs. It can get the type IDs from these
using exprType(), and it can get their locations using exprLocation()
if needed.
We could almost just replace the current form of select_common_type()
with the version envisioned in #2. In a quick grep, there is only
one usage of select_common_type() that isn't invoking it on a list
of exprType() results that could be trivially changed over to the
underlying expressions instead --- and that is in
transformSetOperationTree, which may be dealing with inputs that
are previously-resolved output types for child set operations.
I'm not sure about a better way to complain about type mismatches in
nested set operations, anyway. We could possibly keep track of one of
the sub-expressions that had determined the resolved output type, and
point to that, but it would likely seem a bit arbitrary to the user.
Thoughts anyone?
regards, tom lane