Re: Support UPDATE table SET(*)=... - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support UPDATE table SET(*)=...
Date
Msg-id CAB7nPqTR+LJrKYo4X-S28+zc5Hxp=PSvrbCsR1FbFrQdmS_Jng@mail.gmail.com
Whole thread Raw
In response to Re: Support UPDATE table SET(*)=...  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Support UPDATE table SET(*)=...  (Atri Sharma <atri.jiit@gmail.com>)
List pgsql-hackers
On Wed, Nov 26, 2014 at 4:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think what's likely missing here is a clear design for the raw parse
> tree representation (what's returned by the bison grammar).  The patch
> seems to be trying to skate by without creating any new parse node types
> or fields, but that may well be a bad idea.  At the very least there
> needs to be some commentary added to parsenodes.h explaining what the
> representation actually is (cf commentary there for MultiAssignRef).
>
> Also, I think it's a mistake not to be following the MultiAssignRef
> model for the case of "(*) = ctext_row".  We optimize the ROW-source
> case at the grammar stage when there's a fixed number of target columns,
> because that's a very easy transformation --- but you can't do it like
> that when there's not.  It's possible that that optimization should be
> delayed till later even in the existing case; in general, optimizing
> in gram.y is a bad habit that's better avoided ...
Marking as "returned with feedback" based on those comments.
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Selectivity estimation for inet operators
Next
From: Michael Paquier
Date:
Subject: Re: 9.5: Better memory accounting, towards memory-bounded HashAgg