Heikki Linnakangas <heikki.linnakan...@enterprisedb.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
