Re: [PATCHES] extension for sql update - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: [PATCHES] extension for sql update
Date
Msg-id 1154362102.24186.394.camel@home
Whole thread Raw
In response to Re: [PATCHES] extension for sql update  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Mon, 2006-07-31 at 17:26 +0200, Peter Eisentraut wrote:
> Am Mittwoch, 26. Juli 2006 22:58 schrieb Tom Lane:
> > The reason people want this syntax is that they expect to be
> > able to write, say,
> >
> >     UPDATE mytab SET (foo, bar, baz) =
> >         (SELECT alpha, beta, gamma FROM othertab WHERE key = mytab.key);
> 
> I don't find any derivation in the standard that would permit this.  The only 
> thing I could find are variations on
> 
> SET (a) = x  -- no parentheses
> SET (a, b) = (x, y)
> SET (a, b) = ROW (x, y)
> 
> where x and y are some sort of value expression.  I would have expected the 
> sort of thing that you describe, but if you know how to derive that, I'd like 
> to see it.

I believe <contextually typed row value constructor element list> can be
one or more <value expressions> which includes a <row value expression>.
<row value expression> gives us the <row subquery> option.

For that matter the below portion of <contextually typed row value
constructor> gives us: | <left paren> <contextually typed row value constructor element>
<comma>   <contextually typed row value constructor element list> <right
paren>

This breaks down into one or more comma separated <row subquery>s.

UPDATE tab SET (...) = ((SELECT foo, bar from a), (select bif,baz from
b));

-- 



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Connection limit and Superuser
Next
From: Michael Fuhr
Date:
Subject: Re: tg_trigtuple not NULL in AFTER STATEMENT triggers?