BUG #12664: numeric_recv does not accept large values
The following bug has been logged on the website:
Bug reference: 12664
Logged by: Emil Lenngren
Email address: emil.lenngren@gmail.com
PostgreSQL version: 9.4.0
Operating system: N/A
Description:
According to the documentation for data type "numeric" at
http://www.postgresql.org/docs/9.4/static/datatype-numeric.html:
"up to 131072 digits before the decimal point; up to 16383 digits after the
decimal point"
"Note: The maximum allowed precision when explicitly specified in the type
declaration is 1000; NUMERIC without a specified precision is subject to the
limits described in Table 8-2."
In the binary representation, digits are grouped into groups of 4. The
number of such groups is checked in numeric_recv:
len = (uint16) pq_getmsgint(buf, sizeof(uint16));
if (len < 0 || len > NUMERIC_MAX_PRECISION + NUMERIC_MAX_RESULT_SCALE)
ereport(ERROR,
(errcode(ERRCODE_INVALID_BINARY_REPRESENTATION),
errmsg("invalid length in external \"numeric\" value")));
but NUMERIC_MAX_PRECISION + NUMERIC_MAX_RESULT_SCALE is 3000 which means a
limit of only 12000 digits. numeric_in has no such limit.
The guard should check something like (len > ceil((131072+16383)/4))
instead, or not at all, since the function make_result also checks the
length. Checking for len < 0 also seems a bit needless since len already
contains an unsigned 16-bit value.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
emil.lenngren@gmail.com writes:
According to the documentation for data type "numeric" at
http://www.postgresql.org/docs/9.4/static/datatype-numeric.html:
"up to 131072 digits before the decimal point; up to 16383 digits after the
decimal point"
"Note: The maximum allowed precision when explicitly specified in the type
declaration is 1000; NUMERIC without a specified precision is subject to the
limits described in Table 8-2."
Note that that's not saying anything about how many significant digits
you can write.
In the binary representation, digits are grouped into groups of 4. The
number of such groups is checked in numeric_recv:
len = (uint16) pq_getmsgint(buf, sizeof(uint16));
if (len < 0 || len > NUMERIC_MAX_PRECISION + NUMERIC_MAX_RESULT_SCALE)
ereport(ERROR,
(errcode(ERRCODE_INVALID_BINARY_REPRESENTATION),
errmsg("invalid length in external \"numeric\" value")));
but NUMERIC_MAX_PRECISION + NUMERIC_MAX_RESULT_SCALE is 3000 which means a
limit of only 12000 digits. numeric_in has no such limit.
It's true that numeric_in and numeric_recv aren't too consistent about
the limits they enforce. I doubt that "remove the limits" is the right
answer for that, though. In particular, allowing hundreds of thousands
of digits would be a good way to lock a backend up for very long times
in simple arithmetic operations ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs