On Thu, Jul 29, 2010 at 5:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> Did you look at the
>> patch to move the numeric stuff out of the .h file that I attached a
>> few emails back? If that looks OK, I can commit it and then redo the
>> rest of this along the lines we've discussed.
>
> A couple of thoughts:
>
> * It'd be good to get NUMERIC_HDRSZ out of there too, especially since
> it'll have only the shakiest connection to reality after this patch goes in.
> It looks like doing that would only require modifying type_maximum_size().
> I'd suggest inventing another small function along the lines of
> int32 numeric_maximum_size(int32 typemod)
> so that the NUMERIC-specific knowledge can be pulled out of format_type.c.
>
> * I'd suggest leaving a comment along the lines of
> /* The actual contents of Numeric are private to numeric.c */
> with the now-opaque typedef for Numeric.
>
> Otherwise +1.
Done, with those changes.
But, looking at it a bit more carefully, isn't the maximum-size logic
for numeric rather bogus?
rhaas=# \d n
Table "public.n"
Column | Type | Modifiers
--------+--------------+-----------
a | numeric(2,1) |
rhaas=# select atttypmod from pg_attribute where attrelid =
'n'::regclass and attname = 'a';
atttypmod
-----------
131077
(1 row)
(gdb) p numeric_maximum_size(131077)
$1 = 9
rhaas=# select a, pg_column_size(a),
pg_column_size(a::text::numeric(2,1)) from n;
a | pg_column_size | pg_column_size
-----+----------------+----------------
1.1 | 9 | 12
(1 row)
i.e. According to the max-size logic, the ostensible maximum size of a
numeric(2,1) is 9 bytes, but in fact the real maximum is 12 bytes = 4
byte varlena header + 2 bytes for sign/dscale + 2 bytes for weight +
(2 NumericDigits * 2 bytes/digit).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
