Thread: Money type not gone?
Guys, Pardon me if this is redundant, but I've just noticed that the MONEY type still exists in 8.0b2. Didn't we say that we were getting rid of it? -- Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus <josh@agliodbs.com> writes:
> Pardon me if this is redundant, but I've just noticed that the MONEY type
> still exists in 8.0b2. Didn't we say that we were getting rid of it?
No, we never actually said we would get rid of it, and certainly not on
any particular timetable. I think the only real consensus is that no
one likes the current integer-based implementation. Whether to remove
it or rewrite it is still a matter in dispute.
regards, tom lane
Tom, > No, we never actually said we would get rid of it, and certainly not on > any particular timetable. I think the only real consensus is that no > one likes the current integer-based implementation. Whether to remove > it or rewrite it is still a matter in dispute. My vote is get rid of it and replace it with a DOMAIN of NUMERIC. -- Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus wrote: > My vote is get rid of it and replace it with a DOMAIN of NUMERIC. How would that domain be defined? -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Sun, 2004-09-19 at 15:29 -0400, Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
> > Pardon me if this is redundant, but I've just noticed that the MONEY type
> > still exists in 8.0b2. Didn't we say that we were getting rid of it?
>
> No, we never actually said we would get rid of it, and certainly not on
> any particular timetable. I think the only real consensus is that no
> one likes the current integer-based implementation. Whether to remove
> it or rewrite it is still a matter in dispute.
I want to rewrite it for 8.1 as numeric based datetype with some
formatting extension probably with some internal stuff from to_char()
familly.
Karel
--
Karel Zak
http://home.zf.jcu.cz/~zakkr/
Karel Zak wrote: > On Sun, 2004-09-19 at 15:29 -0400, Tom Lane wrote: > > I want to rewrite it for 8.1 as numeric based datetype with some > formatting extension probably with some internal stuff from to_char() > familly. How about a type that is also able to hold an ISO currency identifier? After a long period of work on multi currency applications, I found out that adding 1 USD and 1 EUR won't give a good result... Regards, Andreas
On Mon, 2004-09-20 at 08:36 +0000, Andreas Pflug wrote:
> Karel Zak wrote:
> > On Sun, 2004-09-19 at 15:29 -0400, Tom Lane wrote:
> >
>
> > I want to rewrite it for 8.1 as numeric based datetype with some
> > formatting extension probably with some internal stuff from to_char()
> > familly.
>
> How about a type that is also able to hold an ISO currency identifier?
My idea is special internal API that will usable for new datetypes
programming if type is defined as "numeric + symbol", for example things
like speed, weight, currency.. etc.
Karel
--
Karel Zak
http://home.zf.jcu.cz/~zakkr/
Karel Zak wrote: > On Mon, 2004-09-20 at 08:36 +0000, Andreas Pflug wrote: > >>Karel Zak wrote: >> >>>On Sun, 2004-09-19 at 15:29 -0400, Tom Lane wrote: >>> >> >>> I want to rewrite it for 8.1 as numeric based datetype with some >>>formatting extension probably with some internal stuff from to_char() >>>familly. >> >>How about a type that is also able to hold an ISO currency identifier? > > > My idea is special internal API that will usable for new datetypes > programming if type is defined as "numeric + symbol", for example things > like speed, weight, currency.. etc. A type consisting of value and unit probably makes pgsql even more first choice for technical applications. Please note that %, k, M and so on are scales, not units and thus dont belong into that type. Regards, Andreas
Karel, Andreas, > > My idea is special internal API that will usable for new datetypes > > programming if type is defined as "numeric + symbol", for example things > > like speed, weight, currency.. etc. > > A type consisting of value and unit probably makes pgsql even more first > choice for technical applications. Please note that %, k, M and so on > are scales, not units and thus dont belong into that type. The difference with currency would be the lack of a fixed conversion for different units. For example, you can: 10m == 1000cm 7l == 0.07m^3 But you can't reasonably: 10USD == 6.25UKL ... because that would require a query to money.yahoo.com to establish. -- Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus wrote: > > The difference with currency would be the lack of a fixed conversion for > different units. For example, you can: You're mixing up quite a lot of stuff here. > 10m == 1000cm This is just what I considered forbidden to be included in that "unit-ed type" in my previous mail. c = centi is a scale, which is up to a view conversion, and should not be stored. It would be a pain to calculate with it. > 7l == 0.07m^3 l is not a SI unit, m^3 is. See below for further handling > But you can't reasonably: > > 10USD == 6.25UKL Yes, right. USD and UKL are different units, and units are generally not convertible. If you want one from the other, you always have to multiply it by something that adapts the units. 1kg = .001m^3 is never true, it needs 1000kg/m^3 as factor for water. Unfortunately, for currencies this isn't fixed (it isn't fixed for water either). l is an abbrevation for .001m^3. If you'd really decide to handle it as unit in the "unit-ed type", it wouldn't be convertible either. Since in real life l and m^3 are rarely used interchanged on a specific item, this seems acceptable. > ... because that would require a query to money.yahoo.com to establish. It's even more complicated. In practice, real time rates of exchanges are much less frequent than point in time rates. Regards, Andreas