Re: persistent portals/cursors (between transactions)

Tom Lane wrote:
> Florian Wunderlich <fwunderlich(at)devbrain(dot)de> writes:
> > But there is no check in CreatePortal or SPI_cursor_open, as far as I've
> > seen, but as SPI doesn't allow transaction control statements I don't
> > know if SPI_connect probably begins a transaction implicitly.
>
> Any sort of SPI operation is implicitly within a transaction, since it
> can (by assumption) only be called from a function, which is being
> called within a query, which is explicitly or implicitly within a
> transaction. So I think the lack of check there is okay.

Since you cannot escalate from an implicit transaction to a
transaction block from inside a function, this was the only
way to enable cursors in PL/pgSQL without the requiremet to
call them inside of an explicit begin/commit block allways.

But I don't like the idea of cross transaction cursors. The
locking issues, mentioned in the code by MAO, which are the
reason for rejecting FOR UPDATE on cursors, should be gone.
And the capability to select for update is a requirement for
updateable cursors, that I intend to work on for 7.3.

So please, no cross transaction cursors only because they
might be handy for ODBC!

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com