Re: expressive test macros (was: Report test_atomic_ops() failures consistently, via macros)

Hi,

On 2019-10-07 13:57:41 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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 disagreement at all.

> 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?

Perhaps it ought to just take elevel as a parameter? Could even be
useful for debugging...

> What will happen in frontend code?

Hm. Map to pg_log_*, and abort() if it's an erroring elevel?

> > 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.

WFM.

Greetings,

Andres Freund