Re: first cut at PL/PgSQL table functions

Tom Lane wrote:
>
> Neil Conway <neilc@samurai.com> writes:
> > Yeah, I agree that special-casing PL/PgSQL is kludgy. Did you read the
> > addendum I posted to my original mail on -patches? Joe Conway and I
> > were discussing how to improve this mechanism -- the idea Joe
> > suggested was to add a new FunctionMode for "this function provides a
> > tuple store", and then add the necessary grammar smarts to make the
> > function mode a property of CREATE FUNCTION. Let me know if I haven't
> > explained Joe's idea in sufficient depth.
>
> I see no reason to push it into the grammar.  Any one SRF is unlikely to
> support more than one return mode (eg, plpgsql SRFs won't) so having the
> function tell the appropriate mode on first call would be sufficient.
> Also, if we push it into the grammar how do we get the user to get it
> right?

I object too and object again.

A PL/pgSQL function might (in the future) want to return a refcursor on
one call, but use RETURN ... AND RESUME on another. So this has to be
done for every SET.

My original idea was to make a tuplestore part of the cursor (Portal
structure). This way the tuplestore access would be hidden behind the
fetching and the caller doesn't have to care what the function really
returns. Also it'd avoid the memory context problem, because the
tuplestore would be part of the Portal memory context and go away when
the cursor is closed.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #