From: | wieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | zakkr(at)zf(dot)jcu(dot)cz (Karel Zak - Zakkr) |
Cc: | wieck(at)debis(dot)com, meskes(at)postgreSQL(dot)org, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Datatype MONEY |
Date: | 1999-12-13 14:03:08 |
Message-ID: | m11xW4C-0003kGC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Karel Zak - Zakkr wrote:
>
> On Mon, 13 Dec 1999, Jan Wieck wrote:
>
> > In some countries (Germany at least) storage of financial
> > booking information is not permitted to use floats. And you
>
> Hmm, interesting.. but it is not problem for to_char(), it is problem
> (how number datetype choise) for users.
But it is subject for what would happen in the expression
first if you have both, to_char(float8, text) and
to_char(numeric, text) available and execute a query with
to_char(444.55, '9999.99').
If the parser could choose to read in the value as float8 and
pass that to to_char(float8, text), the system would not be
compliant to financial software requirements in Germany.
> Or is other idea for to_char() money formatting and how datetype must be
> supported (I plan float4/8 int4/8 now)?
You should at least add NUMERIC to possible inputs. Otherwise
there would be no chance than to convert it to float8,
possibly loosing significant digits (and becoming not
compliant as to above).
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Karel Zak - Zakkr | 1999-12-13 14:14:32 | Re: [HACKERS] Datatype MONEY |
Previous Message | Zeugswetter Andreas SB | 1999-12-13 13:42:46 | Re: [HACKERS] generic LONG VARLENA |