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

Поиск
Список
Период
Сортировка
От Chris Travers
Тема Re: Re: Feature proposal and discussion: full-fledged column/function equivalence
Дата
Msg-id CAKt_Zfv89ZzPBe0-3fty6j7v5PHLwc_EqkpGVjqwAmwtD514kg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Feature proposal and discussion: full-fledged column/function equivalence  (David G Johnston <david.g.johnston@gmail.com>)
Ответы Re: Re: Feature proposal and discussion: full-fledged column/function equivalence  (David Johnston <david.g.johnston@gmail.com>)
Список pgsql-general
Дерево обсуждения



On Fri, Aug 1, 2014 at 12:19 PM, David G Johnston <david.g.johnston@gmail.com> wrote:
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?

Same way you do it for columns.  Throw an error that it is ambiguous.
 

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.

Hmm.  As I see it, there is one possible backwards compatibility issue but it is almost certainly extraordinarily rare.

Suppose in your above example, test_extended has a testfunction attribute but test has a testfunction function.  In the current codebase, there is no parsing ambiguity (the attribute wins because the function is ignored), but we'd have to throw the same error as if the function were an attribute if we did this.

It doesn't seem terribly logically complicated to do this (since it is a slight extension to the lookup in the system catalogs), and I am having trouble imagining that there are many cases where these sorts of functions are added.

The larger question becomes:

Would it be more useful to have such functions in the select * result, or to treat them as hidden columns from that?  (I am thinking that can be decided down the road though if I go through and take this up on -hackers). 

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.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.

В списке pgsql-general по дате отправления:

Предыдущее
От: David G Johnston
Дата:
Сообщение: Re: Feature proposal and discussion: full-fledged column/function equivalence
Следующее
От: Phoenix Kiula
Дата:
Сообщение: Re: Upgrading from 9.0.11 to 9.3.5 on CentOS 6 (64 bit)