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

On Wed, 2008-10-29 at 11:58 -0400, Tom Lane wrote:
> Dimitri Fontaine <dfontaine(at)hi-media(dot)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.

I have some vague ideas about extending SET-returning functions to
NODE-returning functions, which will have some extra methods (for OO
languages like python) or extra functions (for C, somewhat similar to
how AGGREGATE functions are defined) to interact with planner/optimiser,
so that planner can ask the function instance things like "can you do
fast start" or "how many rows for theses args" during planning and also
can advise function about strategies once the plan is chosen.

That would be something which could be very useful for SQL/MED
implementation as well.

-----------------
Hannu

--
------------------------------------------
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training