Re: [HACKERS] New CORRESPONDING clause design - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] New CORRESPONDING clause design
Date
Msg-id CAFj8pRCG3PcK3BpPgnHKX613jrZvMhE2CaP30i7auKKzyYCmvw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] New CORRESPONDING clause design  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


2017-03-18 19:12 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2017-03-18 18:32 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.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.

The corresponding clause is used in UNION queries - these queries can be pretty long, so marking wrong corresponding clause can be helpful.

Probably there are not any other argument for special node,

Regards

Pavel
 

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] New CORRESPONDING clause design
Next
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] PoC plpgsql - possibility to force custom or genericplan