Re: WIP patch: convert SQL-language functions to return tuplestores

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WIP patch: convert SQL-language functions to return tuplestores
Дата
Msg-id 22909.1225295899@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WIP patch: convert SQL-language functions to return tuplestores  (Dimitri Fontaine <dfontaine@hi-media.com>)
Ответы Re: WIP patch: convert SQL-language functions to return tuplestores  (Dimitri Fontaine <dfontaine@hi-media.com>)
Re: WIP patch: convert SQL-language functions to return tuplestores  (Hannu Krosing <hannu@2ndQuadrant.com>)
Список pgsql-hackers
Dimitri Fontaine <dfontaine@hi-media.com> writes:
> And I fail to see how the user would control which behavior will get chosen, 

Oh, I'm sorry, I didn't realize you misunderstood my syntax example.
I was suggesting that the SQL function manager recognize some optional
non-SQL keywords at the start of a SQL function body, along the lines of

CREATE FUNCTION foo(...) RETURNS SETOF something AS $$
#option eager
SELECT ... $$ LANGUAGE SQL;

versus

CREATE FUNCTION foo(...) RETURNS SETOF something AS $$
#option lazy
SELECT ... $$ LANGUAGE SQL;

(I'm not wedded to this particular spelling of it, but there is
precedent in plpgsql.)

Now of course the bigger problem with either this syntax or yours is
that attaching such a property to a function is arguably the Wrong Thing
in the first place.  Which one is the best way is likely to depend on
the calling query more than it does on the function.  However, I see no
solution to that problem except function inlining; and if the function
gets inlined then all this discussion is moot anyhow.
        regards, tom lane


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

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: WIP patch: convert SQL-language functions to return tuplestores
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: PostgreSQL + Replicator developer meeting 10/28