From: | Brendan Jurd <direvus(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Euler Taveira de Oliveira <euler(at)timbira(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: to_char, support for EEEE format |
Date: | 2009-07-30 14:35:49 |
Message-ID: | 37ed240d0907300735p7029220fy667948c817393442@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/7/30 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> 2009/7/29 Brendan Jurd <direvus(at)gmail(dot)com>:
>> I don't see any problem with extending this to allow up to 3 exponent
>> digits ... Pavel, any comment?
>
> I am not sure - this function should be used in reports witl fixed
> line's width. And I am thinking, so it's should be problem - I prefer
> showing some #.### chars. It's clean signal, so some is wrong, but it
> doesn't break generating long run reports (like exception in Oracle)
> and doesn't broke formating like 3 exponent digits.
Hmm. For what it's worth, I think Pavel makes a good point about the
number of exponent digits -- a large chunk of the use case for numeric
formatting would be fixed-width reporting.
Limiting to two exponent digits also has the nice property that the
output always matches the length of the format pattern:
9.99EEEE
1.23E+02
I don't know whether being able to represent 3-digit exponents
outweighs the value of reliable fixed-width output. Would anyone else
care to throw in their opinion? However we end up handling it, we
will probably need to flesh out the docs regarding this.
Cheers,
BJ
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-07-30 14:43:43 | Re: Review: Revise parallel pg_restore's scheduling heuristic |
Previous Message | Magnus Hagander | 2009-07-30 13:35:24 | Re: Compiling Postgres 8.3.7 MSVC 2005 |