Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Well, my opinion is that cursors and other resources should at least be
usable from a inner subtransaction in its parent -- because if that
can't be done we are wasting some of the benefits, because we can't just
"stick everything in a subt
Tom Lane wrote:
BTW, I've been more or less ignoring the nearby debate about whether
cursors ought to roll back at subxact abort or not, because right now
I don't know how to implement *either* behavior. Unless we have
credible theories about how to implement both, it's a bit useless to
debate whi
> begin;
> declare cursor c ...;
> fetch 1 from c; -- returns tuple 1
> begin;
> fetch 1 from c; -- returns tuple 2
> rollback;
> fetch 1 from c; -- returns tuple 1 again
>
> This is mightly ugly but I think it's the most usable of the options
> see
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Yeah. Another answer would be to reset the executor state if the cursor
> is modified in a subtransaction that aborts:
Reset is no solution --- rewinding the cursor to the beginning still
leaves it in a state that is inconsistent with the restored stat
On Thu, Jul 01, 2004 at 10:19:08AM -0400, Tom Lane wrote:
> AFAICS we can't allow an inner transaction to use a cursor that was
> declared in an outer transaction, because if the inner transaction fails
> then it's not just a matter of the FETCH not rolling back; the
> subtransaction abort will re
On Thu, 1 Jul 2004, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Well, my opinion is that cursors and other resources should at least be
> > usable from a inner subtransaction in its parent -- because if that
> > can't be done we are wasting some of the benefits, because we c
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Well, my opinion is that cursors and other resources should at least be
> usable from a inner subtransaction in its parent -- because if that
> can't be done we are wasting some of the benefits, because we can't just
> "stick everything in a subtransacti
