Re: Proposal: Add more compile-time asserts to exposeinconsistencies. - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Proposal: Add more compile-time asserts to exposeinconsistencies.
Date
Msg-id 20191114180735.ipf7xrp4auwtyp6m@alap3.anarazel.de
Whole thread Raw
In response to RE: Proposal: Add more compile-time asserts to exposeinconsistencies.  ("Smith, Peter" <peters@fast.au.fujitsu.com>)
Responses RE: Proposal: Add more compile-time asserts to exposeinconsistencies.  ("Smith, Peter" <peters@fast.au.fujitsu.com>)
List pgsql-hackers
Hi,

On 2019-11-13 03:23:06 +0000, Smith, Peter wrote:
> From: Andres Freund <andres@anarazel.de> Sent: Wednesday, 13 November 2019 6:01 AM
> 
> >Peter Smith:
> >
> > Is there a reason to not just make StaticAssertExpr and StaticAssertStmt be the same? I don't want to proliferate
variantsthat users have to understand if there's no compelling 
 
> > need.  Nor do I think do we really need two different fallback implementation for static asserts.
> 
> >
> > As far as I can tell we should be able to use the prototype based approach in all the cases where we currently use
the"negative bit-field width" approach?
 
> 
> I also thought that the new "prototype negative array-dimension" based
> approach (i.e. StaticAssertDecl) looked like an improvement over the
> existing "negative bit-field width" approach (i.e. StaticAssertStmt),
> because it seems to work for more scenarios (e.g. file scope).
> 
> But I did not refactor existing code to use the new way because I was
> fearful that there might be some subtle reason why the
> StaticAssertStmt was deliberately made that way (e.g. as do/while),
> and last thing I want to do was break working code.

That'll just leave us with cruft. And it's not like this stuff will
break in a subtle way or such....

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: ssl passphrase callback
Next
From: Mark Dilger
Date:
Subject: Re: Using multiple extended statistics for estimates