From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Mike Mascari <mascarm(at)mascari(dot)com>, Mahmoud Taghizadeh <m_taghi(at)yahoo(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: monetary bug |
Date: | 2004-08-23 14:07:29 |
Message-ID: | 20040823140728.GC17568@zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 23, 2004 at 02:52:44PM +0200, Dennis Bjorklund wrote:
> On Mon, 23 Aug 2004, Karel Zak wrote:
>
> > I think it's pretty extendable solution in contrast to the current
> > hardcoded in/out datetypes functions.
>
> Who are we formatting for? If the client wants the data in a specific
> format then they can do SELECT to_char(...), or do the formatting in the
> client all together.
Yes. But some people call for datetypes with integrated formatting (for
example "money"). I think we should support _common_ way how do
formatting (not only for "money") _OR_ we should reject types like
"money" and do formatting only by extra functions like to_char().
> The database should manage data, presenting it to the user in different
> ways are the job of a client.
Sure, do you want to read data in binary format that PostgreSQL uses in
db files or do you expect it in some nice string? PostgreSQL already
does data formating almost for all datetypes -- see sources and
datetypes in/out functions.
Karel
--
Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
http://home.zf.jcu.cz/~zakkr/
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-08-23 14:08:34 | Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE |
Previous Message | Bruce Momjian | 2004-08-23 14:06:48 | Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE |