Peter Childs wrote: > On Mon, 14 Jul 2003, Mike Mascari wrote: > >>Jörg Schulz wrote: >> >>Presumably Oracle is not rolling back a duplicate key violation, >>allowing the transaction to continue. This is an often requested >>feature not present in PostgreSQL. > > > Bug. Not Feature > > Transactions must be all or nothing. If one step fails for what > ever reason all steps must be failed and rolled back. While in this simple > case ignoring the statment may look fine in more complex examples (where > the is more data in the table...) this can mean data loss and massive > problems!
I agree. However a common scenario that has appeared on these lists is a request for an atomic 'CREATE IF NOT EXISTS, ELSE REPLACE' without race conditions. Because Oracle doesn't rollback the transaction, it is implementable in SQL. For PostgreSQL, you either need to use various locking techniques which reduces concurrency or be prepared to resubmit the entire transaction. Savepoints and/or nested transactions may alleviate the situation in the future, however. Mike Mascari [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
