Re: revised patch for PL/PgSQL table functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: revised patch for PL/PgSQL table functions
Date: 2002-08-30 00:39:22
Message-ID: 15381.1030667962@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2002-08-30 00:42:28 Re: [HACKERS] Proposed GUC Variable
Previous Message Joe Conway 2002-08-30 00:21:44 Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management