Re: [HACKERS] static assertions in C++ - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] static assertions in C++
Date
Msg-id 30209.1511967787@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] static assertions in C++  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] static assertions in C++  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Nov 29, 2017 at 9:26 AM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> I'd still like a review of this patch.

> I don't think there's much to review apart from this one issue.
> Neither Tom nor I seem to be convinced about:
> +/* not worth providing a workaround */
> I suggested that it was worth providing a workaround, and Tom
> suggested that the case might be so rare that we could just #error if
> happens.  If you agree that it's never likely to come up, I suggest
> going with Tom's #error proposal; otherwise, I suggest trying to find
> a workable workaround.

Right now, we have the property that every build enforces static
assertions, albeit with variable quality of the error messages.
I strongly disagree that it's okay to throw that property away.
I do think that we could put an #error here instead, and wait to see
if anyone complains before expending effort on a workaround.

> Apart from that, the only thing I see is that it seems like the
> comment block just before your code changes might need some updating.

Agreed, that would need some love as well.  I have no other comments
either.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: es_query_dsa is broken
Next
From: Robert Haas
Date:
Subject: Re: using index or check in ALTER TABLE SET NOT NULL