From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Use new overflow aware integer operations. |
Date: | 2017-12-22 23:16:42 |
Message-ID: | D060B40F-5781-4981-B853-509D06E7DCD0@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On December 22, 2017 7:52:54 PM GMT+01:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2017-12-22 11:00:54 -0500, Tom Lane wrote:
>>> I do not think it is reasonable for these functions to not set the
>>> output variable at all in the overflow case; it is not their job
>>> to opine on whether the caller may use the result.
>
>> I don't agree. Please note that that the function's documentation
>> explicitly says "The content of *result is implementation defined in
>> case of overflow.".
>
>I will not accept an implementation that spews compiler warnings
>all over the place, which is what this one is doing. Please fix that,
>or else I will.
Are you seriously implying that I'm suggesting that we live with a warning / that I refuse to fix one? All I was saying is that I don't want to exactly define which value *result is set to in case of overflow. Without having resolved the discussion of semantics it just seemed pointless to start fixing...
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-12-23 20:26:22 | Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple |
Previous Message | Tom Lane | 2017-12-22 18:52:54 | Re: pgsql: Use new overflow aware integer operations. |