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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: expressive test macros (was: Report test_atomic_ops() failures consistently, via macros)
Date: 2019-10-07 17:57:41
Message-ID: 2144.1570471061@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian 2019-10-07 18:33:40 pgsql: doc: move mention of log_min_error_statement in a better spot
Previous Message Tom Lane 2019-10-07 16:39:32 pgsql: Check for too many postmaster children before spawning a bgworke

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-10-07 18:14:34 Re: identity column behavior in WHEN condition for BEFORE EACH ROW trigger
Previous Message Dent John 2019-10-07 17:55:20 Re: [PATCH] Do not use StdRdOptions in Access Methods