PG_RE_THROW is mandatory (was Re: jsonpath)

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>, Andres Freund <andres@anarazel.de>, Nikita Glukhov <n.gluhov@postgrespro.ru>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Oleg Bartunov <obartunov@postgrespro.ru>, Michael Paquier <michael@paquier.xyz>, Stas Kelvich <s.kelvich@postgrespro.ru>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Thomas Munro <thomas.munro@enterprisedb.com>, David Steele <david@pgmasters.net>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, Craig Ringer <craig@2ndquadrant.com>
Date: 2019-02-06T16:09:59Z
Lists: pgsql-hackers
In https://postgr.es/m/1676.1548726280@sss.pgh.pa.us Tom Lane wrote:

> Sure: every errcode we have is unsafe to treat this way.
> 
> The backend coding rule from day one has been that a thrown error requires
> (sub)transaction cleanup to be done to make sure that things are back in a
> good state.  You can *not* just decide that it's okay to ignore that,
> especially not when invoking code outside the immediate area of what
> you're doing.

elog.h claims that PG_RE_THROW is "optional":

/*----------
 * API for catching ereport(ERROR) exits.  Use these macros like so:
 *
 *		PG_TRY();
 *		{
 *			... code that might throw ereport(ERROR) ...
 *		}
 *		PG_CATCH();
 *		{
 *			... error recovery code ...
 *		}
 *		PG_END_TRY();
 *
 * (The braces are not actually necessary, but are recommended so that
 * pgindent will indent the construct nicely.)	The error recovery code
 * can optionally do PG_RE_THROW() to propagate the same error outwards.

This is obviously wrong; while we have a couple of codesites that omit
it, it's not a generally available coding pattern.  I think we should
amend that comment.  I propose: "The error recovery code must normally
do PG_RE_THROW() to propagate the error outwards; failure to do so may
leave the system in an inconsistent state for further processing."

Other wording proposals welcome, but I don't want to leave it as is.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Commits

  1. Fix misleading PG_RE_THROW commentary