Re: Problem with aborting entire transactions on error - Mailing list pgsql-general

From Martin French
Subject Re: Problem with aborting entire transactions on error
Date
Msg-id OF849A3AF2.03106DC2-ON80257AD0.00569B2B-80257AD0.00584D45@romaxtech.com
Whole thread Raw
In response to Re: Problem with aborting entire transactions on error  (Zbigniew <zbigniew2011@gmail.com>)
List pgsql-general
> if { no error during query } { 
>   do it 
> } else { 
>  withdraw this one 
>  if { ROLLBACK_ON_ERROR } { 
>    rollback entire transaction 
>   } 
> } 

I fear that this is no-where near as simple as it's been taken for, and without looking at the code, I would imagine that this would touch so many different areas, that a simple implementation is just not possible.

Ask yourself; How do other DBMS systems handle this?

MySQL has "INSERT IGNORE"
MSSQL has PRIMARY KEY WITH IGNORE_DUP_KEY
Oracle has a couple of ways of doing this, one of which logs the data (using a DBMS package) the other is with MERGE.

So, maybe you need to have a look at a postgres sepcific way of doing this, seeing as other DBMS's can't seem to agree? Maybe shorter save points so you lose only partial data?

Also, you might want to read some of the discussions here, as in my opinion, what you're looking for is best solved with MERGE.
http://wiki.postgresql.org/wiki/SQL_MERGE

Cheers
=============================================

Romax Technology Limited
Rutherford House
Nottingham Science & Technology Park
Nottingham,
NG7 2PZ
England

Telephone numbers:
+44 (0)115 951 88 00 (main)

For other office locations see:
http://www.romaxtech.com/Contact
=================================
===============
E-mail: info@romaxtech.com
Website:
www.romaxtech.com
=================================

================
Confidentiality Statement
This transmission is for the addressee only and contains information that is confidential and privileged.
Unless you are the named addressee, or authorised to receive it on behalf of the addressee
you may not copy or use it, or disclose it to anyone else.
If you have received this transmission in error please delete from your system and contact the sender. Thank you for your cooperation.
=================================================

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Out of memory error
Next
From: François Beausoleil
Date:
Subject: ANALYZE and partitioning