Re: Supporting multiple column assignment in UPDATE (9.5 project)
От | Marko Tiikkaja |
---|---|
Тема | Re: Supporting multiple column assignment in UPDATE (9.5 project) |
Дата | |
Msg-id | 5364C982.7060003@joh.to обсуждение исходный текст |
Ответ на | Re: Supporting multiple column assignment in UPDATE (9.5 project) (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: Supporting multiple column assignment in UPDATE (9.5 project)
|
Список | pgsql-hackers |
On 5/2/14, 10:10 PM, Merlin Moncure wrote: > On Fri, May 2, 2014 at 3:03 PM, Tom Lane <tgl@sss.pgh.pa.us> 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. Regards, Marko Tiikkaja
В списке pgsql-hackers по дате отправления: