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