Re: Feature proposal and discussion: full-fledged column/function equivalence - Mailing list pgsql-general

From David G Johnston
Subject Re: Feature proposal and discussion: full-fledged column/function equivalence
Date
Msg-id 1406920747771-5813571.post@n5.nabble.com
Whole thread Raw
In response to Re: Feature proposal and discussion: full-fledged column/function equivalence  (Vik Fearing <vik.fearing@dalibo.com>)
Responses Re: Re: Feature proposal and discussion: full-fledged column/function equivalence  (Chris Travers <chris.travers@gmail.com>)
List pgsql-general
Vik Fearing wrote
>> CREATE testfunction(test) returns int language sql as $$ select 1; $$;
>> SELECT testfunction FROM test;
>>
>> That would allow first-class calculated columns.
>>
>> I assume the work is mostly at the parser/grammatical level.  Is there
>> any reason why supporting that would be a bad idea?
>
> This is already supported since forever.
>
> SELECT test.testfunction FROM test;

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?

SELECT testfunction FROM test JOIN test_extended USING (test_id)

I guess you could allow for the non-ambiguous cases and error out otherwise
but that seems to be adding quite a bit of complexity for little gain.

David J.



--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Feature-proposal-and-discussion-full-fledged-column-function-equivalence-tp5813533p5813571.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


pgsql-general by date:

Previous
From: Larry White
Date:
Subject: Re: Very Limited Toast Compression on JSONB (9.4 beta 2)
Next
From: Chris Travers
Date:
Subject: Re: Re: Feature proposal and discussion: full-fledged column/function equivalence