Re: first cut at PL/PgSQL table functions

Tom Lane wrote:
> 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?

Well one reason is that in the future we might want to be able to
specify a *sorted* FunctionMode and make use of that in the optimizer.
But I suppose the concept of "sorted" is orthogonal to the "mode" (i.e.
we can send sorted results either by steaming or as a tuplestore batch).

So how do we pass the mode info from the function back up the line to
FunctionNext? Would it make sense to add a member to ExprContext? It
gets passed in to the function as part of ReturnSetInfo.

> 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.

Does a good primer on proper backend memory-context handling exist? If
so I'd love a cheat-sheet version that I could laminate ;-)

Joe