On Mon, Oct 23, 2017 at 01:27:43AM -0700, Andres Freund wrote:
> On 2017-10-22 23:04:50 -0400, Tom Lane wrote:
> > 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.
>
> It'd probably be a good idea to expand on this in the sgml docs. This
> has confused quite anumber of people...
I know this is from 2017, but where would we document this? I don't see
PG_TRY/PG_CATCH mentioned in the SGML docs at all.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.