From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Simplifying our Trap/Assert infrastructure
In-reply-to: <20221009210148.GA900071@nathanxps13>
References: <3928703.1665345117@sss.pgh.pa.us>
 <20221009210148.GA900071@nathanxps13>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Sun, 09 Oct 2022 14:01:48 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3943008.1665349719.1@sss.pgh.pa.us>
Date: Sun, 09 Oct 2022 17:08:39 -0400
Message-ID: <3943009.1665349719@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3943009.1665349719%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> On Sun, Oct 09, 2022 at 03:51:57PM -0400, Tom Lane wrote:
>> Hence, I propose the attached.

> The patch LGTM.  It might be worth removing usages of AssertArg and
> AssertState, too, but that can always be done separately.

Something I thought about but forgot to mention in the initial email:
is it worth sprinkling these macros with "unlikely()"?  I think that
compilers might assume the right thing automatically based on noticing
that ExceptionalCondition is noreturn ... but then again they might
not.  Of course we're not that fussed about micro-optimizations in
assert-enabled builds; but with so many Asserts in the system, it
might still add up to something noticeable if there is an effect.

			regards, tom lane