John Lumby <johnlumby@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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers