From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | "Smith, Peter" <peters(at)fast(dot)au(dot)fujitsu(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "ilmari(at)ilmari(dot)org" <ilmari(at)ilmari(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Add more compile-time asserts to expose inconsistencies. |
Date: | 2019-12-04 09:09:28 |
Message-ID: | 7107be28-dc7f-34e5-bd80-1260b0732e50@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-12-02 16:55, Andres Freund wrote:
>> +StaticAssertDecl(lengthof(LockTagTypeNames) == (LOCKTAG_ADVISORY + 1),
>> + "LockTagTypeNames array inconsistency");
>> +
> These error messages strike me as somewhat unhelpful. I'd probably just
> reword them as "array length mismatch" or something like that.
I'd prefer it if we could just get rid of the second argument and show
the actual expression in the error message, like run-time assertions work.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Hubert Zhang | 2019-12-04 09:13:57 | Re: Yet another vectorized engine |
Previous Message | Tatsuro Yamada | 2019-12-04 08:53:42 | Re: progress report for ANALYZE |