From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Oliver Elphick <olly(at)lfix(dot)co(dot)uk>, hackers postgres <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Re: [QUESTIONS] money or dollar type |
Date: | 1998-05-12 05:17:43 |
Message-ID: | 3557DB77.BC72C128@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> However, what money *really* needs is more precision. Has there been
> any thought of working on the full SQL exact-numeric package?
Yes. The problem is that afaik there is no variable-width exact numeric
package available. BCD arithmetic could work if a package were
available. The GNU extended precision package looks interesting, but we
would have to translate from a string to internal format for every
operation, or somehow store the internal representation in each tuple
which seems messy.
I'm thinking of moving the 64-bit integer contrib package I wrote into
the native backend as a foundation for the numeric/decimal data types.
We would need to get feedback from more of the supported platforms on
how to do 64-bit integers (a few processors have them as a "long" type,
and the GNU 32-bit compilers seem to allow a "long long" declaration,
but I don't know what other systems do for this).
The only other thing which would need to be handled is how to pass along
the two value precision/scale parameters which are a part of the
declaration for these types. I've just finished working on the type
conversion algorithms so understand the current "atttypmod" field a bit
better, but have not decided how to extend it to multiple fields.
- Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Carlos Navarro Garcia | 1998-05-12 06:00:00 | Portals again |
Previous Message | Bruce Momjian | 1998-05-12 03:19:57 | Re: [HACKERS] Re: [PATCHES] Try again: S_LOCK reduced contentionh] |