Re: Problem with aborting entire transactions on error

From: Виктор Егоров <vyegorov(at)gmail(dot)com>
To: Thomas Kellerer <spam_eater(at)gmx(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Problem with aborting entire transactions on error
Date: 2012-12-10 19:25:18
Message-ID: CAGnEbojLuDV3w-ZGtDpbCDig07orWSjP+pEAR8dMVfkrTn7PUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2012/12/10 Thomas Kellerer <spam_eater(at)gmx(dot)net>
>
> Zbigniew, 10.12.2012 04:20:
>>
>> Yes, I read about using "savepoints" - but I think we agree,
>> it's just cumbersome workaround - and not real solution,
>
>
> It might be a bit cumbersome, but it *is* a proper solution to the problem - not a workaround.

Writing scripts for ORACLE's sqlplus, I have the option to write
"whenever sqlerror exit sql.sqlcode;" and get the behavior similar to
setting psql's ON_ERROR_STOP variable.

On the other hand, it is possible to write "whenever sqlerror
continue;" and this will make ORACLE to process all the statements
inide the script, ignoring all errors. This is a general feature,
available not only for sqlplus scripts — as mentioned, a series of 100
INSERTs can have 5 failing ones and commit statement will result in 95
new records..

So, in order to get similar behavior using current PostgreSQL
features, one will have to:
1) use savepoints
2) use single-statement transactions;
3) (crazy stuff) use triggers on a fake relation to “test” inserts
into the real one and ignore filing ones;
4) do pre-processing in some external tool, like script or pgloader;
5) more options?

All these options will give significant performance and/or scripting
penalty, while, say ORACLE, does it “for free” — I don't know the
mechanics behind this feature, so looks like “free as in free speech”
to me.

The original OP's post is a feature request, IMHO.

I'm not sure whether it is a good thing to have in general, but I
really had to use it my scripts several times.

--
Victor Y. Yegorov

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2012-12-10 19:34:53 Re: Literal NUL using COPY TO
Previous Message Dan S 2012-12-10 19:13:08 Bug in GET STACKED DIAGNOSTICS ?