Nested transactions may end up getting PostgreSQL there, but it still has to
be internally implemented. Applications expect that when an exception is
thrown then only the SQL call that generated the transaction rolled back.
Any SQL calls in the same transaction successfully completed prior would
still be there waiting for the commit or rollback call. Having nested
transactions might make it easier for the internal DB code to define a save
point prior to each SQL call so that it can rollback to that point if a SQL
exception is thrown.
On Wednesday 27 November 2002 11:42 am, Bruce Momjian wrote:
> Jon Swinth wrote:
> > The other feature is to allow transactions to continue without being
> > forced to rollback when a SQL exception occurs. In many applications, a
> > SQL exception is handled and an appropriate alternative generated so the
> > transaction goes on. PostgreSQL does not support this and errors on
> > every call made in the same transaction before calling rollback. Some
> > people are willing and able to adjust there application code to handle
> > this. Many people have long running transactions where this is not
> > easily accomplished or are using a pre-existing application that they
> > can't change.
>
> I am going to try to add nested transactions in 7.4. Will that help
> you?