On Thu, Jul 29, 2010 at 5:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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
