Tom Lane <tgl@sss.pgh.pa.us> writes:
> Neil Conway <neilc@samurai.com> writes:
>
> [ new improved address, eh? ]
heh, yeah :-) FYI, my old address will work for the next two weeks or
so, at which it will probably bounce...
> > - nodeFunctionscan.c special-cases set-returning PL/PgSQL
> > functions.
>
> <<itch>> No, that wasn't something I'd ever have suggested. The
> nodeFunctionscan.c code should let the called function *tell* it
> which return convention the function wants to use. We don't want to
> prevent, say, dblink.c from using this feature once it's in.
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.
Any comment on the scheme we had been thinking of using, as opposed to
the design you suggested?
Also, we had intended that this could wait for 7.4, given how little
time there is remaining before the beta.
> > - memory allocation
[...]
> It would probably be appropriate for ReturnSetInfo to include a
> field showing which context to create the returned tuplestore in.
Ok, that might work.
> Or it might do to just have the function return it in the calling
> context, in which case SPI_palloc *would* work.
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.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
