Re: WIP: to_char, support for EEEE format

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, 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-08-02 15:49:38
Message-ID: 162867790908020849q1a5fb3faye28cf06cfbc30d50@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/8/2 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Thu, Jul 30, 2009 at 1:18 PM, Pavel Stehule<pavel(dot)stehule(at)gmail(dot)com> wrote:
>> 2009/7/30 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>>>> 2009/7/30 Robert Haas <robertmhaas(at)gmail(dot)com>:
>>>>> On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd<direvus(at)gmail(dot)com> wrote:
>>>>>> 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.
>>>
>>> +1.  If you aren't trying to get the format exactly so, it's not clear
>>> why you're bothering with to_char() at all.
>>>
>>>> Maybe we should to support some modificator like Large EEEE - LEEEE or EEEEE
>>>
>>> Five (or more?) E's seems like a natural extension to me.  However, that
>>> still leaves us with the question of what to do when the exponent
>>> doesn't fit in however many digits we'd like to print.  Seems like the
>>> options are
>>>        * print #'s
>>>        * force the output wider
>>>        * throw an error
>>> None of these are very nice, but the first two could cause problems that
>>> you don't find out until it's too late to fix.  What about throwing an
>>> error?
>>
>> I thing, so Oracle raise error. But I don't thing, so it is necessary
>> repeat all Oracle the behave - mainly when is maybe not too much
>> practical.
>>
>> * print #s, and force the output wider has one disadvantage - it
>> cannot put clean signal about data problem in development time, maybe
>> we should to add raise warning.
>>
>> * throw an error should to break "bad" written application in
>> production, when is too late too. So anybody should have not complete
>> test data set and there are a problem.
>>
>> I prefer print # with raising an warning.
>
> It seems like the discussion here has kind of died.  We need to settle
> on an approach and get a final patch soon, or else defer this until
> next CommitFest.

Tom, please, can you write your opinion on my last proposal - print
### with raise warning.

regards
Pavel
>
> ...Robert
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2009-08-02 16:06:40 Re: machine-readable explain output v4
Previous Message Pavel Stehule 2009-08-02 15:46:51 Re: mixed, named notation support