Subject | RE: [Firebird-Architect] NUMERIC vs DECIMAL |
---|---|
Author | Claudio Valderrama C. |
Post date | 2003-08-07T09:01:58Z |
Pavel Cisar wrote:
Yeah, the engine says that decimal has rdb$field_length being 4
(rdb$field_type=7) and numeric, length=2 (field_type=8), in bytes, of
course.
Both have the same scale (-1) due to my example.
Field sub-type is 1 for numeric, 2 for decimal.
But we have rdb$field_precision that's set correctly for both domains at 2.
This explains why isql can get the correct metadata extraction.
Hence, the only thing we need to do is to enforce precision for the NUMERIC
type.
C.
> Claudio,Creating two domains: numeric(2,1) v/s decimal(2,1).
>
> On 6 Aug 2003 at 6:56, Claudio Valderrama C. wrote:
>
>> - Both numeric and decimal behave the same. Numeric isn't SQL
>> compliant currently.
>>
>> - For both dialects, being "p" the precision, the internal storage
>> is: 1 <= p <= 4 => smallint
>
> Are you sure ? I'd swear that decimal is stored as INTEGER (32bit) as
> documented. I checked that some time ago on FB 1.0.2 (? don't
> remember, but I'd also swear this apply to both dialects). But my
> memory is often lousy, so the reality check is needed.
Yeah, the engine says that decimal has rdb$field_length being 4
(rdb$field_type=7) and numeric, length=2 (field_type=8), in bytes, of
course.
Both have the same scale (-1) due to my example.
Field sub-type is 1 for numeric, 2 for decimal.
But we have rdb$field_precision that's set correctly for both domains at 2.
This explains why isql can get the correct metadata extraction.
Hence, the only thing we need to do is to enforce precision for the NUMERIC
type.
C.