Re: expressive test macros (was: Report test_atomic_ops() failures consistently, via macros) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: expressive test macros (was: Report test_atomic_ops() failures consistently, via macros)
Date
Msg-id 2144.1570471061@sss.pgh.pa.us
Whole thread Raw
In response to expressive test macros (was: Report test_atomic_ops() failuresconsistently, via macros)  (Andres Freund <andres@anarazel.de>)
Responses Re: expressive test macros (was: Report test_atomic_ops() failuresconsistently, via macros)
Re: expressive test macros (was: Report test_atomic_ops() failuresconsistently, via macros)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2019-10-05 17:08:38 +0000, Noah Misch wrote:
>> Report test_atomic_ops() failures consistently, via macros.

> I wonder if we should put these (and a few more, for other types), into
> a more general place. I would like to have them for writing both tests
> like regress.c:test_atomic_ops(), and for writing assertions that
> actually display useful error messages.  For the former it makes sense
> to ERROR out, for the latter they ought to abort, as currently.

IMO, anything named like "assert" ought to act like Assert does now,
ie (1) it's a no-op in a non-assert build and (2) you get an abort()
on failure.  No strong opinions about what the test-and-elog variant
should be called -- but it seems like we might have some difficulty
agreeing on what the appropriate error level is for that.  If it's
morally like an Assert except we want it on all the time, should
it be PANIC?  What will happen in frontend code?

> Seems like putting ASSERT_{EQ,LT,...}_{U32,S32,...} (or Assert_Eq_...,
> but that'd imo look weirder than the inconsistency) into c.h would make
> sense, and EXPECT_ somewhere in common/pg_test.h or such?

I'd just put them all in c.h.  I see no reason why a new header
is helpful.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Dent John
Date:
Subject: Re: [PATCH] Do not use StdRdOptions in Access Methods
Next
From: Peter Eisentraut
Date:
Subject: Re: identity column behavior in WHEN condition for BEFORE EACH ROWtrigger