Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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.
Thanks Tom.
> 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.
Yes, I probably should have mentioned that. I considered adding the
code to generate a TupleDesc for each call of RETURN NEXT and compare
that to the TupleDesc used for the previous RETURN NEXT statement, but
that seems to be quite expensive: equalTupleDescs() is not cheap, and
neither is TyoeGetTupleDesc() (which is required for returning
non-RECORD vars). Since RETURN NEXT will often be called many times
within a single function, the performance hit seems unappealing. Is
there a better way?
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
