Re: Supporting multiple column assignment in UPDATE (9.5 project) - Mailing list pgsql-hackers

From David G Johnston
Subject Re: Supporting multiple column assignment in UPDATE (9.5 project)
Date
Msg-id 1399304116687-5802471.post@n5.nabble.com
Whole thread Raw
In response to Re: Supporting multiple column assignment in UPDATE (9.5 project)  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-hackers
Merlin Moncure-2 wrote
> On Sat, May 3, 2014 at 5:48 AM, Marko Tiikkaja <

> marko@

> > wrote:
>> On 5/2/14, 10:10 PM, Merlin Moncure wrote:
>>>
>>> On Fri, May 2, 2014 at 3:03 PM, Tom Lane <

> tgl@.pa

> > wrote:
>>>>
>>>> Meh.  Then you could have a query that works fine until you add a
>>>> column
>>>> to the table, and it stops working.  If nobody ever used column names
>>>> identical to table names it'd be all right, but unfortunately people
>>>> seem to do that a lot...
>>>
>>>
>>> That's already the case with select statements
>>
>> I don't think that's true if you table-qualify your column references and
>> don't use SELECT *.
>>
>>
>>> and, if a user were
>>> concerned about that, always have the option of aliasing the table as
>>> nearly 100% of professional developers do:
>>>
>>> SELECT f FROM foo f;
>>> etc.
>>
>>
>> So e.g.:
>>
>>   UPDATE foo f SET f = ..;
>>
>> would resolve to the table, despite there being a column called "f"? That
>> would break backwards compatibility.
>>
>> How about:
>>
>>   UPDATE foo SET ROW(foo) = (1,2,3);
>>
>> ISTM that this could be parsed unambiguously, though it's perhaps a bit
>> ugly.
> 
> Hm, that's a bit too ugly: row(foo) in this case means 'do special
> behavior X' whereas in all other cases it means make an anonymous
> rowtype with one attribute of type 'foo'.
> 
> How about:
> UPDATE foo SET (foo).* = (1,2,3);

Wouldn't

UPDATE foo SET (foo.*) = (1,2,3)

be better since it would cleanly support non-complete types like

UPDATE foo SET (foo.col1, foo.col3) = (1,3)

Though I am not that concerned about overloading the use of "ROW" in context
of an UPDATE.

As with normal usage of ROW why not make its presence optional - support
both syntaxes?

Keywords like USING and SET have different meanings when used in
DELETE/UPDATE so having ROW behave similarly wouldn't be that confusing -
and it does seem to have an ambiguity if you restrict this interpretation of
ROW to only the SET of the update statement.

Is there any need or requirement for (or against) interleaving normal and
row-valued, or even multiple row-valued, SET expressions?

UPDATE foo SET (foo.col1, foo.col3) = (1,3), foo.col2 = 2

David J.





--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Supporting-multiple-column-assignment-in-UPDATE-9-5-project-tp5802240p5802471.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.



pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Supporting multiple column assignment in UPDATE (9.5 project)
Next
From: Andres Freund
Date:
Subject: Re: Cluster name in ps output