Re: BUG #13850: Need a parameter added similar to "edb_stmt_level_tx"
От | Pavel Stehule |
---|---|
Тема | Re: BUG #13850: Need a parameter added similar to "edb_stmt_level_tx" |
Дата | |
Msg-id | CAFj8pRDSAnfybaq7Ls51KahgPXBmzy8gQVhCacTXjbkFOJdbug@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #13850: Need a parameter added similar to "edb_stmt_level_tx" (extra43@comcast.net) |
Список | pgsql-bugs |
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 >
В списке pgsql-bugs по дате отправления: