Re: revised patch for PL/PgSQL table functions
От | Neil Conway |
---|---|
Тема | Re: revised patch for PL/PgSQL table functions |
Дата | |
Msg-id | 87sn0xlzc9.fsf@mailbox.samurai.com обсуждение исходный текст |
Ответ на | Re: revised patch for PL/PgSQL table functions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: revised patch for PL/PgSQL table functions
Re: revised patch for PL/PgSQL table functions |
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: