Re: Bug in PL/pgSQL FOR cursor variant

On 21/06/10 22:25, Tom Lane wrote:
> 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.

Oh, I see. I didn't realize that unnamed cursors are still accessible to 
anyone with the "" name.

> On the performance end, redoing SPI_cursor_find every row seems like
> rather a large penalty ...

Granted.

Maybe it would be easier to somehow protect the portal then, and throw 
an error if you try to close it. We could just mark the portal as 
PORTAL_ACTIVE while we run the user statements, but that would also 
forbid fetching or moving it. I'm thinking of a new "pinned" state, 
which is like PORTAL_READY except that the portal can't be dropped like 
in PORTAL_ACTIVE state.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com