Re: first cut at PL/PgSQL table functions

Neil Conway <neilc(at)samurai(dot)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?

> Also, we had intended that this could wait for 7.4, given how little
> time there is remaining before the beta.

No, this is something that has to be gotten right the first time, or
there are going to be compatibility constraints in the way of improving
it.

> I was originally allocating the tuple store in the same context used
> by SPI_palloc(), but the backend was segfaulting after the PL/PgSQL
> function returned (IIRC it was during the second call to
> FunctionNext(), but my memory's a bit fuzzy). I haven't looked into
> this a lot -- if you think SPI_palloc() is the right way to go, let me
> know and I'll try to track down the problem.

It's quite likely that that won't work at present, depending on what
sort of context-flinging is done in nodeFunctionscan. I need to review
that code and see if I think the context handling is good or not.
Will try to look today.

regards, tom lane