Re: Better error message for select_common_type()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Better error message for select_common_type()
Date: 2007-04-23 23:02:30
Message-ID: 16140.1177369350@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2007-04-23 23:33:11 Re: Better error message for select_common_type()
Previous Message Alvaro Herrera 2007-04-23 22:26:47 Re: Improving deadlock error messages