From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Surafel Temesgen <surafel3000(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New CORRESPONDING clause design |
Date: | 2017-03-18 18:12:31 |
Message-ID: | 6249.1489860751@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2017-03-18 18:32 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> I definitely don't see a reason for CORRESPONDING to track locations of
>> name list elements when no other name list productions do. It might be
>> worth proposing a followon patch to change all of them (perhaps by adding
>> a location field to struct "Value") and then make use of the locations in
>> error messages more widely.
> I had a idea use own node for CORRESPONDING with location - and using this
> location in related error messages.
I think using a private node type for CORRESPONDING is exactly the wrong
thing. It's a columnList and it should be like other columnLists. If
there's an argument for providing a location for "no such column" errors
for CORRESPONDING, then surely there's also an argument for providing
a location for "no such column" errors for FOREIGN KEY and the other
places where we have lists of column names.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2017-03-18 18:22:28 | Re: New CORRESPONDING clause design |
Previous Message | Fujii Masao | 2017-03-18 18:03:37 | Re: Renaming of pg_xlog and pg_clog |