Re: persistent portals/cursors (between transactions)

Tom Lane wrote:
> Florian Wunderlich <fwunderlich@devbrain.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@Yahoo.com #



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