On 12/20/17 10:51, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 12/20/17 00:57, Tom Lane wrote:
>>> I do not have a well-informed opinion on whether
>>> #if defined(__cpp_static_assert) && __cpp_static_assert >= 200410
>>> is an appropriate test for static_assert() being available, but I'm
>>>
Peter Eisentraut writes:
> On 12/20/17 00:57, Tom Lane wrote:
>> I do not have a well-informed opinion on whether
>> #if defined(__cpp_static_assert) && __cpp_static_assert >= 200410
>> is an appropriate test for static_assert() being available, but I'm
>> pretty suspicious of it because none of m
On 12/20/17 00:57, Tom Lane wrote:
> I do not have a well-informed opinion on whether
>
> #if defined(__cpp_static_assert) && __cpp_static_assert >= 200410
>
> is an appropriate test for static_assert() being available, but I'm
> pretty suspicious of it because none of my C++ compilers seem to
>
Peter Eisentraut writes:
> On 12/11/17 17:12, Tom Lane wrote:
>> Hmm, well, surely there's more than one way to do that; the sizeof
>> is just a convenient way to wrap it in C. Wouldn't a typedef serve
>> just as well?
> Here is another attempt, which has the desired effect with the handful
> of
On 12/11/17 17:12, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 12/11/17 16:45, Tom Lane wrote:
>>> (BTW, why is it that we can't fall back on the negative-width-bitfield
>>> trick for old g++?)
>
>> The complaint is
>> error: types may not be defined in 'sizeof' expressions
>
> Hmm, well, s
Peter Eisentraut writes:
> On 12/11/17 16:45, Tom Lane wrote:
>> (BTW, why is it that we can't fall back on the negative-width-bitfield
>> trick for old g++?)
> The complaint is
> error: types may not be defined in 'sizeof' expressions
Hmm, well, surely there's more than one way to do that; the
On 12/11/17 16:45, Tom Lane wrote:
>> I guess the question is whether we would rather be able to have users
>> continue to use older C++ compilers, or be super picky about static
>> assertions.
>
> Uh, what is this "continue to use" bit? We've never supported
> building the backend with C++ compi
Peter Eisentraut writes:
> On 11/29/17 10:03, Tom Lane wrote:
>> 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
On 11/29/17 10:03, Tom Lane wrote:
> 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 t
Andres Freund writes:
> On 2017-11-29 16:39:14 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> FWIW, I think that's a perfectly reasonable choice. Adding complications
>>> in making static assertions work for random archaic compilers when
>>> compiling with c++ just doesn't seem worth more th
On 2017-11-29 16:39:14 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-11-29 09:41:15 -0500, Robert Haas wrote:
> >> +/* not worth providing a workaround */
>
> > FWIW, I think that's a perfectly reasonable choice. Adding complications
> > in making static assertions work for random ar
Andres Freund writes:
> On 2017-11-29 09:41:15 -0500, Robert Haas wrote:
>> +/* not worth providing a workaround */
> FWIW, I think that's a perfectly reasonable choice. Adding complications
> in making static assertions work for random archaic compilers when
> compiling with c++ just doesn't see
On 2017-11-29 09:41:15 -0500, Robert Haas wrote:
> On Wed, Nov 29, 2017 at 9:26 AM, Peter Eisentraut
> 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
Robert Haas writes:
> On Wed, Nov 29, 2017 at 9:26 AM, Peter Eisentraut
> 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 tha
On Wed, Nov 29, 2017 at 9:26 AM, Peter Eisentraut
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 worka
On 11/29/17 00:35, Michael Paquier wrote:
> On Fri, Sep 1, 2017 at 8:28 AM, Robert Haas wrote:
>> On Thu, Aug 31, 2017 at 6:37 PM, Tom Lane wrote:
>>> Meh. We support ancient versions of C for backwards compatibility
>>> reasons, but considering that compiling backend code with C++ isn't
>>> off
On Fri, Sep 1, 2017 at 8:28 AM, Robert Haas wrote:
> On Thu, Aug 31, 2017 at 6:37 PM, Tom Lane wrote:
>> Meh. We support ancient versions of C for backwards compatibility
>> reasons, but considering that compiling backend code with C++ isn't
>> officially supported at all, I'm not sure we need t
17 matches
Mail list logo
