Hi
2016-01-06 0:07 GMT+01:00 <extra43@comcast.net>:
> The following bug has been logged on the website:
>
> Bug reference: 13850
> Logged by: David Skinner
> Email address: extra43@comcast.net
> PostgreSQL version: 9.5rc1
> Operating system: Windows
> Description:
>
> To add support for PostgreSQL, we need the equivalent of EDB's
> edb_stmt_level_tx parameter, which you can see explained here:
>
> http://www.enterprisedb.com/docs/en/8.4/oracompat/Postgres_Plus_Advanced_Server_Oracle_Compatibility_Guide-04.htm
>
> We've read all about the new "ON CONFLICT" keyword in 9.5, but coding it
> into our complex ECM product would be kludgy and an incomplete fix. Our
> use
> case (for example) is adding a folder, and preventing a duplicate key error
> on the (enforced unique) containment name.
>
> Rather than rollback and retry the entire txn, we only need to catch the
> SQL
> error and retry the INSERT (which failed on dup. key error). There are
> similar situations in over 50 places in our code that relies on NOT rolling
> back the txn on SQL error. NOT rolling back is the standard behavior on
> Oracle, SQL Server, Informix and DB2. We understand the reasons for PG's
> current behavior, but it is not practical in the complex real world,
> especially since it should be extremely simple to support as EDB has.
> Thanks! Also, when is 9.5 GA expected?
>
This isn't a bug. You can write a proposal to PostgreSQL mailing list
http://www.postgresql.org/list/pgsql-hackers/
Postgres has similar function implemented in psql
http://blog.endpoint.com/2015/02/postgres-onerrorrollback-explained.html.
Implementation inside procedures isn't difficult - it require
subtransaction for any statement, that means significant performance
impact. So it isn't enabled by default, and you have to use exception
trapping.
Regards
Pavel Stehule
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>