David Johnston <david.g.johnston@xxxxxxxxx> writes: > On Fri, Aug 1, 2014 at 6:22 PM, Chris Travers <chris.travers@xxxxxxxxx> > wrote: >> On Fri, Aug 1, 2014 at 12:19 PM, David G Johnston < >> david.g.johnston@xxxxxxxxx> wrote: >>> More to the point: if you are writing a multiple-relation query and have >>> "testfunction" functions defined for at least two of the relations used in >>> the query how would the system decide which one to use? >> Same way you do it for columns. Throw an error that it is ambiguous. > â??I'd rather approach the first-class issue by being able to say: ALTER > TABLE test ADD COLUMN â??testfunction(test) -- maybe with an "AS col_alias"... The real reason not to do this is that there is already a SQL standard feature for computed columns (they're called generated columns IIRC). We don't need to, and shouldn't, invent nonstandard syntax for that. We inherited the notion that "a.b is equivalent to b(a)" from PostQUEL; it's nowhere to be seen in SQL. While I don't feel a need to incur the backwards compatibility hit of taking that out, I also don't feel a need to extend it, especially not in directions that risk breaking existing applications. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
