Re: Bug in PL/pgSQL FOR cursor variant

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> On 21/06/10 17:08, Tom Lane wrote:
>> Also, isn't exec_for_query() at just as much risk?
>> The latter's problem would only be exposed if the cursor was closed
>> at a batch boundary, but it's still a problem.

> Can you elaborate? I thought I fixed exec_for_query(). (except for the
> missing pstrdup).

Oh, I thought I'd read the whole patch, but I see I missed the last
part. But it doesn't matter, because that's still broken, both as to
performance and security. prefetch_ok is not meant to be bulletproof,
only to ensure that in cases where the cursor is *meant* to be exposed
to the user its behavior is as he expects. If you're trying to stop a
crash you need to realize that people can get at any portal at all.
On the performance end, redoing SPI_cursor_find every row seems like
rather a large penalty ...

regards, tom lane