On Wednesday, 30 September 2020 20:37:23 CEST, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
> Matthias Apitz <guru@unixarea.de> writes:
>> El día miércoles, septiembre 30, 2020 a las 05:26:39p. m.
>> +0200, Laurenz Albe escribió:
>>> On Wed, 2020-09-30 at 13:32 +0000, Wiltsch,Sigrid wrote:
>>>> What can I do so that the cursor is retained despite rollback?
>
>>> You cannot start a transaction while you are reading a
>>> cursor; you probably
>>> get a warning "there is already a transaction in progress".
>
>> I think we will prepare the ten-liner in ESQL/C for further discussion.
>
> I don't think you really need to: the point seems clear enough.
>
> I don't especially like the idea you are suggesting though. The general
> principle in SQL is that a rolled-back transaction should have no effect
> after it's been rolled back. Allowing a cursor it creates to survive
> the rollback would fly in the face of that principle.
The general idea of transactions is that you START one at a moment,
go ahead and a ROLLBACK rolls back everything what was done *after* the
point of starting it.
We have here the case of not beeing able to define the start of
the transaction. The application wants to set it *after* the first (and
again after
each next) fetch. You say, the transaction starts already with that fetch.
We have to think how to deal with that missing feature in PostgreSQL
ESQL/C to define the point of where the transaction starts.
Btw: In all of the other DBS (Informix, Sybase, Oracle) we could define
that point
with START TRANSACTION.
Thanks
matthias
--
Sent from my Ubuntu phone
http://www.unixarea.de/
NO to the EU! NEIN zur EU!