Re: New version of money type

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: New version of money type
Date: 2006-09-14 15:17:29
Message-ID: 45097289.7070609@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

D'Arcy J.M. Cain wrote:
> On Thu, 14 Sep 2006 07:59:07 -0700
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote:
>> D'Arcy J.M. Cain wrote:
>>> For years I have been promising that a 64 bit version of the money type
>>> was on the way. Here it is. So far it compiles and I have done some
>>> basic testing on it and it seems to work fine. Note that the currency
>>> symbol is also dropped on output as well but it is accepted on input.
>> Not to come down on your hard work, but isn't the money type deprecated?
>
> Not by me. :-)

Obviously ;), but it is deprecated by the project.

>
> The biggest argument about the money type is that it has an unrealistic
> limit. With this change we can go to almost one hundred thousand
> trillion dollars. That should handle even the US federal budget for a
> few more years.

Isn't that what numeric is for?

>
> The benefit of the money type is speed. Because internal operations
> are done on integers they can generally be handled by single CPU ops.
> My tests on the 64 bit version show 10% to 25% improvement over numeric
> for many operations.

Well that is certainly cool :) I will leave it to others to determine if
we should include it.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-09-14 15:20:30 Re: [ADMIN] Vacuum error on database postgres
Previous Message Russ Brown 2006-09-14 15:15:34 Optimising a query requiring seqscans=0