SOCI/soci — pull request #134 by vadz (2013-04-13 22:51:47+00:00)
Title: Don't allow exceptions escape from postgresql_statement_backend dtor.

I'm not totally sure about this one, there may (must?) be a better way of dealing with this, perhaps by remembering if we're inside a transaction and not deallocating the statement if an error happens in this case (or maybe there is some better way at PG API level? Unfortunately I just don't know it well enough...). But OTOH letting the exceptions escape from the dtor remains a very bad idea (unfortunately this is not the only place where this happens in SOCI...) because aborting the entire application just because of an integrity violation at the database level is not acceptable. So this is probably a good thing to do anyhow.

Commit message:

----
This fixes abnormal program termination if an error happened while executing a
prepared statement: it was then destroyed during stack unwinding and if
deallocating it failed as well, resulting in a call to terminate().

In practice, deallocation seems to always fail with SQL state 25P02 ("current
transaction is aborted, commands ignored until end of transaction block") when
it is executed inside a transaction.