Re: revised patch for PL/PgSQL table functions - Mailing list pgsql-patches

From Tom Lane
Subject Re: revised patch for PL/PgSQL table functions
Date
Msg-id 15381.1030667962@sss.pgh.pa.us
Whole thread Raw
In response to Re: revised patch for PL/PgSQL table functions  (Neil Conway <neilc@samurai.com>)
Responses Re: revised patch for PL/PgSQL table functions  (Neil Conway <neilc@samurai.com>)
List pgsql-patches
Neil Conway <neilc@samurai.com> writes:
> I've attached a revised patch: rediffed against CVS HEAD, changed the
> RETURN NEXT parsing as suggested by Tom above, and made some more
> minor cleanups to PL/PgSQL code.

I've applied this patch with some editorializing --- mainly, I didn't
like hardwiring the functionality to plpgsql, so I extended the
ReturnSetInfo interface instead.  Now anybody can use the
return-a-tuplestore mechanism for SRFs.

There is a rather nasty bug left (Sir Mordred would likely call it a
DOS possibility ;-)) --- RETURN NEXT doesn't seem to be checking that
the row or record variable it is given actually matches the declared
return type of the plpgsql function.  You could probably cause problems
by passing the wrong thing, or even more subtly by passing the right
thing on the first RETURN NEXT and then wrong things later.  This
needs to be tightened up.

Another thing to think about is extending plpgsql to support functions
declared to return RECORD, ie, the first value actually passed to RETURN
or RETURN NEXT determines the result tuple type.  I won't cry if we
don't get that feature into 7.3, though.

            regards, tom lane

pgsql-patches by date:

Previous
From: Joe Conway
Date:
Subject: Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Proposed GUC Variable