>Andrej Czapszys
> This is a major bug which greatly diminishes the confidence of my
> co-workers in postgresql.
This is NOT a bug. Transactional robustness is important and PostgreSQL
has a very strict implementation in this area.
>Greg Stark
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Edwin S. Ramirez wrote:
> > > Is is possible to change the transaction behaviour not to abort
when a
> > > syntax error occurs.
> > >
> > > I've done some searches on the list, and have not found anything.
> >
> > No, we need nested transactions for that. We are working on it or
at
> > least have a plan.
>
> I'm not clear why nested transactions are necessary. Oracle certainly
> doesn't
> require dealing with nested transactions to get this, and its been a
long
> time
> but I don't recall MSSQL doing anything like that either. If I recall
> correctly they both do this by automatically by default.
Greg is correct I believe. DB2 also implements transactions in this way.
There are other databases which have historically implemented
Transaction control in this way, notably earlier versions of Teradata
RDBMS.
Most importantly, other references I have state that: the ANSI SQL-99
specification does require that if a statement errors then only that
statement's changes are rolled back. Control is returned to the calling
application to decide what to do. Some statement types are theoretically
retryable, such as those which have been evicted because of deadlock
errors, so this is a normal situation (on some rdbms!).
Having said that it's not a bug, I'm not sure exactly where it says it
behaves like this in the PostgreSQL manual. I've checked the ANSI SQL-99
unsupported features section and nothing springs out at me from there;
if anybody has a copy of the actual spec could they check on this, so we
can at least document carefully the current behaviour.
Archaeology aside :), I couldn't comment on whether implementing this in
PostgreSQL would require the equivalent of nested transaction behaviour.
If Bruce says so...
Also this makes me think there may be some investigation required into
XA two-phase commit behaviour regarding this point. Anybody?
Best regards, Simon Riggs
