2014-05-05 17:02 GMT+02:00 Merlin Moncure <mmonc...@gmail.com>: > On Sat, May 3, 2014 at 5:48 AM, Marko Tiikkaja <ma...@joh.to> wrote: > > On 5/2/14, 10:10 PM, Merlin Moncure wrote: > >> > >> On Fri, May 2, 2014 at 3:03 PM, Tom Lane <t...@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. > > 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); >
It is looking little bit strange I like previous proposal UPDATE foo SET foo = (1,2,3); Pavel > > merlin > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
