>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 <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
