Peter Eisentraut <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers