Re: Re: Feature proposal and discussion: full-fledged column/function equivalence

David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Fri, Aug 1, 2014 at 6:22 PM, Chris Travers <chris(dot)travers(at)gmail(dot)com>
> wrote:
>> On Fri, Aug 1, 2014 at 12:19 PM, David G Johnston <
>> david(dot)g(dot)johnston(at)gmail(dot)com> 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