Re: Proposal: Add more compile-time asserts to exposeinconsistencies.
От | Andres Freund |
---|---|
Тема | Re: Proposal: Add more compile-time asserts to exposeinconsistencies. |
Дата | |
Msg-id | 20191114180735.ipf7xrp4auwtyp6m@alap3.anarazel.de обсуждение исходный текст |
Ответ на | RE: Proposal: Add more compile-time asserts to exposeinconsistencies. ("Smith, Peter" <peters@fast.au.fujitsu.com>) |
Ответы |
RE: Proposal: Add more compile-time asserts to exposeinconsistencies.
|
Список | 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 по дате отправления: