From c603b392c32513982439bc466312d3a6b697d53e Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Mon, 11 Feb 2019 15:55:09 -0300 Subject: [PATCH] Fix misleading PG_RE_THROW commentary The old verbiage indicated that PG_RE_THROW is optional, which is not really true. This has confused many people, so it seems worth fixing. Discussion: https://postgr.es/m/20190206160958.GA22304@alvherre.pgsql --- src/include/utils/elog.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/include/utils/elog.h b/src/include/utils/elog.h index 648eedf5af7..7ac37fd270e 100644 --- a/src/include/utils/elog.h +++ b/src/include/utils/elog.h @@ -272,8 +272,10 @@ extern PGDLLIMPORT ErrorContextCallback *error_context_stack; * 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. + * pgindent will indent the construct nicely.) The error recovery code + * can either do PG_RE_THROW to propagate the error outwards, or do a + * (sub)transaction abort. Failure to do so may leave the system in an + * inconsistent state for further processing. * * Note: while the system will correctly propagate any new ereport(ERROR) * occurring in the recovery section, there is a small limit on the number -- 2.39.5