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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: expressive test macros (was: Report test_atomic_ops() failures consistently, via macros)
Дата
Msg-id 2144.1570471061@sss.pgh.pa.us
обсуждение исходный текст
Ответ на expressive test macros (was: Report test_atomic_ops() failuresconsistently, via macros)  (Andres Freund <andres@anarazel.de>)
Ответы Re: expressive test macros (was: Report test_atomic_ops() failuresconsistently, via macros)  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Re: expressive test macros (was: Report test_atomic_ops() failuresconsistently, via macros)  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Dent John
Дата:
Сообщение: Re: [PATCH] Do not use StdRdOptions in Access Methods
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: identity column behavior in WHEN condition for BEFORE EACH ROWtrigger