On 2017-10-22 23:04:50 -0400, Tom Lane wrote: > John Lumby <johnlu...@hotmail.com> writes: > > I have a C function (a trigger function) which uses the PG_TRY() > > construct to handle certain ERROR conditions. > > One example is where invoked as INSTEAD OF INSERT into a view. It > > PG_TRYs INSERT into the real base table, > > but this table may not yet exist (it is a partitioned child of an > > inheritance parent). > > If the error is ERRCODE_UNDEFINED_TABLE, then the CATCH issues > > FlushErrorState() and returns to caller who CREATes the table and > > re-issues the insert. > > All works perfectly (on every release of 9.x). > > If it works, it's only because you didn't try very hard to break it. > In general you can't catch and ignore errors without a full-fledged > subtransaction --- BeginInternalSubTransaction, then either > ReleaseCurrentSubTransaction or RollbackAndReleaseCurrentSubTransaction, > not just FlushErrorState. See e.g. plpgpsql's exec_stmt_block. > > There may well be specific scenarios where an error gets thrown without > having done anything that requires transaction cleanup. But when you > hit a scenario where that's not true, or when a scenario that used to > not require cleanup now does, nobody is going to consider that a PG bug.
It'd probably be a good idea to expand on this in the sgml docs. This has confused quite anumber of people... Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
