Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group