BUG #7529: Support different error handling behavior than auto rollback - Mailing list pgsql-bugs

From legoharyanto@gmail.com
Subject BUG #7529: Support different error handling behavior than auto rollback
Date
Msg-id E1TBAVQ-0002tp-S7@wrigleys.postgresql.org
Whole thread Raw
Responses Re: BUG #7529: Support different error handling behavior than auto rollback  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-bugs
The following bug has been logged on the website:

Bug reference:      7529
Logged by:          Lego Haryanto
Email address:      legoharyanto@gmail.com
PostgreSQL version: 9.0.5
Operating system:   Any
Description:        =


I understand that current transaction behavior in PostgreSQL is to throw
away the whole transaction away (rollback) if there's at least one error
within the transaction.

I believe on certain application of data replication, say, migration from
other database source, ... this will be pretty cumbersome to support in
PostgreSQL even though users have some conflict resolution strategy in
mind.

On the following scenario, imagine this transaction is coming from a source
of different DB, migrating into a PostgreSQL target.

BEGIN
  INSERT #1... (success)
  INSERT #2... (success)
  INSERT #3... (error or conflict/collision)
  INSERT #4... (success)
COMMIT;

Current behavior of PostgreSQL is that the INSERT #4 command is ignored
because of the error on INSERT #3 (subsequent commands are ignored).

And the COMMIT command is accepted as ROLLBACK, which we can argue it's
misleading because user does an explicit COMMIT, but the actual action is a
rollback.

Can we actually support honoring the successful DMLs above, and do the
actual COMMIT that is inserting #1, #2, and #4 in above example?

pgsql-bugs by date:

Previous
From: mwtoews@gmail.com
Date:
Subject: BUG #7530: initdb.exe ignores --locale option, uses "English_United States.1252"
Next
From: Pavel Stehule
Date:
Subject: Re: BUG #7529: Support different error handling behavior than auto rollback