money type overflow checks
The input function of the money type has no overflow checks:
=> select '12345678901234567890'::money;
money
-----------------------------
-$13,639,628,150,831,692.72
(1 row)
The tests in the regression test file money.sql are bogus because they
only test the overflow checks of the bigint type before the cast.
Here is a patch that adds appropriate checks and tests. We could
probably remove the bogus tests.
(Is checking for < 0 a valid overflow check? We save the sign until the
very end, so it ought to work. The code in int8.c works differently there.)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Add-overflow-checks-to-money-type-input-function.patchtext/x-patch; name=0001-Add-overflow-checks-to-money-type-input-function.patchDownload+76-1
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
The input function of the money type has no overflow checks:
Ugh.
(Is checking for < 0 a valid overflow check?
No, I don't think it's sufficient after a multiplication by 10. That
would be enough to shift some bits clear out of the word, but there's
no certainty that the new sign bit would be 1.
The scheme used in scanint8 is safe. But I think it was written that way
mainly to avoid hard-wired assumptions about how wide int64 is, a
consideration that's a mite obsolete now. You could possibly avoid the
cost of a division by relying on comparisons to PG_INT64_MAX/10.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 8/5/16 1:14 PM, Tom Lane wrote:
No, I don't think it's sufficient after a multiplication by 10. That
would be enough to shift some bits clear out of the word, but there's
no certainty that the new sign bit would be 1.The scheme used in scanint8 is safe. But I think it was written that way
mainly to avoid hard-wired assumptions about how wide int64 is, a
consideration that's a mite obsolete now.
OK, I did it like int8, and added more tests. My original patch didn't
get the most negative integer right.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services