Обсуждение: BUG #13850: Need a parameter added similar to "edb_stmt_level_tx"
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?
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 >