On Fri, 9 Jul 2004, Alvaro Herrera wrote:
> I mean this:
>
> begin;
> ... work ...;
> savepoint foo;
> ... more work ...;
> savepoint bar;
> ... yet more ... ;
> release foo;
>
>
> At this time I can't release savepoint foo because the implementation
> (nested) requires me to keep it open as long as savepoint bar exists.
> If I released bar at a later time, I could close both, but not before.
Yes, and that is exactly what should be done, what is wrong with that
behaviour?
If you do the same as above with nested transactions
BEGIN; ... work ...; SUBBEGIN; ... more work ...; SUBBEGIN; ... yet more ... ;
and now you can only commit the last subbegin. Subtransactions does not
give you anything more then savepoints in this example.
If anything there might be a possibility to do more with savepoints then
nested transactions since as you say, you can release an earlier savepoint
then the last. But that is something one can try to optimize later, if
possible to optimize at all.
Subtransactions can _not_ free more things then savepoints can. It's just
an empty argument.
In fact, I still see no real advantage to subtransactions at all. We are
only playing the lock-in game when we introduce postgresql features that
do almost the same thing as standard features.
--
/Dennis Björklund
