From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Zhihong Yu <zyu(at)yugabyte(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: avoid negating LONG_MIN in cash_out() |
Date: | 2022-08-11 19:55:05 |
Message-ID: | CAApHDvq0Gn0Ey3qv9S39KEZCgueOt=zBhs7LSL2Vf0wcfNA5mg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 12 Aug 2022 at 05:58, Zhihong Yu <zyu(at)yugabyte(dot)com> wrote:
> Here is sample output with patch:
>
> # SELECT '-92233720368547758.085'::money;
> ERROR: value "-92233720368547758.085" is out of range for type money
> LINE 1: SELECT '-92233720368547758.085'::money;
I'm struggling to follow along here. There are already overflow checks
for this in cash_in(), which is exactly where they should be.
The above case already fails on master, there's even a regression test
to make sure it does for this exact case, just look at money.out:356.
So, if we're already stopping this from happening in cash_in(), why do
you think it also needs to happen in cash_out()?
I'm also not sure why you opted to use LONG_MIN for your check. The C
type "Cash" is based on int64, that's not long.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-08-11 20:03:43 | test failure with gcc-12 -O3 -march=native |
Previous Message | Andres Freund | 2022-08-11 19:27:13 | Re: tests and meson - test names and file locations |