Re: WIP patch: convert SQL-language functions to return tuplestores - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP patch: convert SQL-language functions to return tuplestores
Date
Msg-id 22909.1225295899@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP patch: convert SQL-language functions to return tuplestores  (Dimitri Fontaine <dfontaine@hi-media.com>)
Responses Re: WIP patch: convert SQL-language functions to return tuplestores
Re: WIP patch: convert SQL-language functions to return tuplestores
List 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 by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: WIP patch: convert SQL-language functions to return tuplestores
Next
From: "Joshua D. Drake"
Date:
Subject: Re: PostgreSQL + Replicator developer meeting 10/28