On Sun, 2009-10-04 at 17:12 +0100, Sam Mason wrote:
There is an open source library by IBM that I use in my C++ code to do
this, and may be it can be incorporated into PG
it is called decNumber
http://speleotrove.com/decimal/decnumber.html
How would this help over PG's existing
Christophe Pettus wrote:
On Oct 4, 2009, at 7:09 PM, Guy Rouillier wrote:
There is no reason why PG could not support packed decimal.
Is that not NUMERIC?
No, that is not NUMERIC. All numeric types are stored as binary
representations. Packed decimal is not. Perhaps an example would
Guy Rouillier wrote:
Christophe Pettus wrote:
On Oct 4, 2009, at 7:09 PM, Guy Rouillier wrote:
There is no reason why PG could not support packed decimal.
Is that not NUMERIC?
No, that is not NUMERIC. All numeric types are stored as binary
representations. Packed decimal is
A quick check of the source code (src/backend/utils/adt/numeric.c)
shows it's base 1, each digit represented as an int16. It's not
strictly speaking BCD, but there's no computational difference.
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-general mailing list
On Mon, Oct 05, 2009 at 01:07:16PM -0700, Christophe Pettus wrote:
A quick check of the source code (src/backend/utils/adt/numeric.c)
shows it's base 1, each digit represented as an int16.
I was going to note that in my post but thought it was needless detail;
ah well, maybe next time I
Bruce Momjian wrote:
Guy Rouillier wrote:
Christophe Pettus wrote:
On Oct 4, 2009, at 7:09 PM, Guy Rouillier wrote:
There is no reason why PG could not support packed decimal.
Is that not NUMERIC?
No, that is not NUMERIC. All numeric types are stored as binary
representations. Packed
Guy Rouillier wrote:
The IBM implementation provided language libraries (usually COBOL)
that also supported packed decimal, so precision was maintained
throughout the entire application stack.
IBM 360/370/390/etcetc/Zsystem has BCD op codes in the instruction set
architecture. microcoded
Withing PG procedures at least in pgsql it is impossible to do 'money'
calculations
without a loss of precision.
There is an open source library by IBM that I use in my C++ code to do
this, and may be it can
be incorporated into PG
it is called decNumber
On Sat, Oct 03, 2009 at 10:14:53PM -0400, V S P wrote:
Withing PG procedures at least in pgsql it is impossible to do 'money'
calculations without a loss of precision.
The point is that on *any* computer it's impossible to perform arbitrary
calculations to infinite precision (i.e. without a
On Sun, 4 Oct 2009, Sam Mason wrote:
Withing PG procedures at least in pgsql it is impossible to do 'money'
calculations without a loss of precision.
The point is that on *any* computer it's impossible to perform arbitrary
calculations to infinite precision (i.e. without a loss of precision
On Sun, Oct 04, 2009 at 09:31:02AM -0700, Rich Shepard wrote:
On Sun, 4 Oct 2009, Sam Mason wrote:
The point is that on *any* computer it's impossible to perform arbitrary
calculations to infinite precision (i.e. without a loss of precision as
you put it).
I've not followed this tread,
Rich Shepard wrote:
In the early and mid-1980s we used a procedure for business
applications
involving money that worked regardless of programming language or
platform.
To each (float, real) monetary amount we added 0.005 and truncated the
result
to two digits on the right of the decimal
Rich Shepard wrote:
On Sun, 4 Oct 2009, Sam Mason wrote:
Withing PG procedures at least in pgsql it is impossible to do 'money'
calculations without a loss of precision.
The point is that on *any* computer it's impossible to perform arbitrary
calculations to infinite precision (i.e. without
On Oct 4, 2009, at 7:09 PM, Guy Rouillier wrote:
There is no reason why PG could not support packed decimal.
Is that not NUMERIC?
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
I've noticed that while you can perform various calculations on a column of
type money, you can't use it or cast it as any other numeric type directly.
Furthermore, it appears that since the locale being applied to the type is
cluster-wide, you would need an entirely different cluster if say you
Hi Thom,
Here's how I represent currency values:
CREATE DOMAIN currency
AS numeric(10,2);
I understand money has been deprecated. It has one obvious flaw that I
can think of: It cannot represent different currencies in different
tuples, with a currency_id field.
Regards,
Peter Geoghegan
--
depending on the countries, etc - keep currencies in 10.4 , or you can
compromise to 10.3 , otherwise you might run into problems with rounding,
etc.
2009/10/3 Peter Geoghegan peter.geoghega...@gmail.com
Here's how I represent currency values:
CREATE DOMAIN currency
AS numeric(10,2);
See, I can understand why someone might take the extra step to create a
domain for storing monetary units. The fact that money is in the
documentation,
On 03/10/2009 11:53, Grzegorz Jaśkiewicz wrote:
depending on the countries, etc - keep currencies in 10.4 , or you can
compromise to 10.3 , otherwise you might run into problems with
rounding, etc.
I thought the idea of NUMERIC was that the value was exact, avoiding
rounding problems that you
On Sat, 2009-10-03 at 11:33 +0100, Thom Brown wrote:
I've found that I unwittingly compiled PostgreSQL on my web server
without specifying locale,
PostgreSQL isn't compiled with a locale or without one.
and now the money type is represented in dollars. In order to change
that, it would
On 03/10/2009 11:33, Thom Brown wrote:
I've found that I unwittingly compiled PostgreSQL on my web server
without specifying locale, and now the money type is represented in
You specify the locale at the initdb stage, not when compiling.
Ray.
2009/10/3 Raymond O'Donnell r...@iol.ie
You specify the locale at the initdb stage, not when compiling.
Ray.
Yes, you're right. Got my wires crossed there. However, it still means
locale-per-cluster which is disappointing. Ideally we'd have collation and
locale per table or even per
I understand it's kind of a survey, so to answer the question from my point
of view:
The money data type is not useful at all.
--
Filip Rembiałkowski
JID,mailto:filip.rembialkow...@gmail.com
http://filip.rembialkowski.net/
2009/10/3 Grzegorz Jaśkiewicz gryz...@gmail.com:
depending on the countries, etc - keep currencies in 10.4 , or you can
compromise to 10.3 , otherwise you might run into problems with rounding,
etc.
I myself don't find it useful to store currency values that include
fractions of a cent. I'm
On Sat, Oct 03, 2009 at 12:20:57PM +0100, Raymond O'Donnell wrote:
I thought the idea of NUMERIC was that the value was exact, avoiding
rounding problems that you might get with other floating-point types?
Nope, sorry it's still a computer and thus can't represent anything
with infinite
On Sat, Oct 3, 2009 at 11:40 AM, Sam Mason s...@samason.me.uk wrote:
On Sat, Oct 03, 2009 at 12:20:57PM +0100, Raymond O'Donnell wrote:
I thought the idea of NUMERIC was that the value was exact, avoiding
rounding problems that you might get with other floating-point types?
Nope, sorry it's
2009/10/3 Grzegorz Jaśkiewicz gryz...@gmail.com:
depending on the countries, etc - keep currencies in 10.4 , or you can
compromise to 10.3 , otherwise you might run into problems with rounding,
etc.
Keeping more digits of precision than the application actually can use
is more likely to
On Sat, Oct 03, 2009 at 11:49:50AM -0400, Merlin Moncure wrote:
On Sat, Oct 3, 2009 at 11:40 AM, Sam Mason s...@samason.me.uk wrote:
it's still a computer and thus can't represent anything
with infinite precision (just numeric fractions in PG's case, let alone
irrational numbers).
I
28 matches
Mail list logo
