Re: Supporting multiple column assignment in UPDATE (9.5 project)

Поиск
Список
Период
Сортировка
От David G Johnston
Тема Re: Supporting multiple column assignment in UPDATE (9.5 project)
Дата
Msg-id 1399304116687-5802471.post@n5.nabble.com
обсуждение исходный текст
Ответ на Re: Supporting multiple column assignment in UPDATE (9.5 project)  (Merlin Moncure <mmoncure@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Supporting multiple column assignment in UPDATE (9.5 project)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Cluster name in ps output