From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Mitch Vincent <mitch(at)venux(dot)net>, pgsql-sql(at)postgreSQL(dot)org |
Subject: | Re: [SQL] numeric question.. |
Date: | 2000-01-16 17:35:34 |
Message-ID: | 20835.948044134@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> NUMERIC specifies the data type exact numeric, with the decimal precision
> and scale specified by the <precision> and <scale>.
> DECIMAL specifies the data type exact numeric, with the decimal scale
> specified by the <scale> and the implementation-defined decimal precision
> equal to or greater than the value of the specified <precision>.
> Up to this day I'm wondering what exactly this means ...
Yeah, I read that too. I think what it means is that implementors are
allowed to increase the precision (field width) of a DECIMAL field to a
larger value if that's more efficient in their implementation, whereas
NUMERIC must have exactly the specified precision.
For example, if we were to reimplement NUMERIC using radix-10000
arithmetic (four decimal digits per 16-bit integer), then the most
efficient field widths would be multiples of 4. According to the spec,
we'd be allowed to increase the field width of a DECIMAL field to make
it a multiple of 4, but not the width of a NUMERIC field.
Right now, there is no such implementation advantage in Postgres, so
the two field types are exactly equivalent in our code.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gerhard Dieringer | 2000-01-17 08:12:53 | Antw: [SQL] attribute level rules not supported? |
Previous Message | Peter Eisentraut | 2000-01-16 17:14:04 | Re: [SQL] numeric question.. |