| 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: | Whole Thread | Raw Message | 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 |