On Fri, May 2, 2014 at 3:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Merlin Moncure <mmonc...@gmail.com> writes: >> On Fri, May 2, 2014 at 2:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> But I don't think your suggestions of the table name or alias work; >>> they could conflict with an actual column name. > >> Presumably it'd follow similar rules to SELECT -- resolve the column >> name in the face of ambiguity. > > 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 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. Now, I need this feature a lot less than I used to (although I do like the symmetry with SELECT); hstore and jsonb have matured to the point that they can handle most trigger function operations that you'd want to abstract over multiple tables without expensive calls to information_schema. The main advantages for a native approach would be type safety (although even that situation is improving at long last), performance, and code complexity. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers