From: | emil(dot)lenngren(at)gmail(dot)com |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | BUG #12664: numeric_recv does not accept large values |
Date: | 2015-01-25 20:51:46 |
Message-ID: | 20150125205146.6452.25810@wrigleys.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 12664
Logged by: Emil Lenngren
Email address: emil(dot)lenngren(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | warrior2031 | 2015-01-26 12:41:33 | BUG #12670: Can't create postgis extension in single-user mode |
Previous Message | RAFAŁ BAŁAZY | 2015-01-25 19:51:32 | PostgreSQL - Installation on Windows 8 - I need help |