Skip site navigation (1) Skip section navigation (2)

Re: WIP: to_char, support for EEEE format

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2009-07-30 14:43:43
Subject: Re: Review: Revise parallel pg_restore's scheduling heuristic
Previous:From: Magnus HaganderDate: 2009-07-30 13:35:24
Subject: Re: Compiling Postgres 8.3.7 MSVC 2005

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group