Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> +1 on using the parser location mechanism and avoiding the
>> terminology problem altogether.
> I figured we would let the parser only point to the UNION or VALUES or
> whatever word. It would be fairly cumbersome to drag the individual
> expression positions down into select_common_value() for full
> precision.
Possibly. I was thinking of demanding that callers pass an additional
list containing positions for the expressions, but hadn't looked to see
how easy that might be. In any case, if we need to point at both
expressions then it's not gonna work.
For the VALUES case, the suggestion of "row" and "column" terminology
seems the right thing, but for UNION it would be better to use "branch"
perhaps ("row" certainly seems misleading). How can we make that work
without indulging in untranslatable keyword-insertion?
Another possibility is "alternative" and "column", which seems like it
applies more or less equally poorly to both cases.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
