Re: WIP: to_char, support for EEEE format - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: WIP: to_char, support for EEEE format
Date
Msg-id 162867790908020849q1a5fb3faye28cf06cfbc30d50@mail.gmail.com
Whole thread Raw
In response to Re: WIP: to_char, support for EEEE format  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: WIP: to_char, support for EEEE format  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2009/8/2 Robert Haas <robertmhaas@gmail.com>:
> On Thu, Jul 30, 2009 at 1:18 PM, Pavel Stehule<pavel.stehule@gmail.com> wrote:
>> 2009/7/30 Tom Lane <tgl@sss.pgh.pa.us>:
>>> Pavel Stehule <pavel.stehule@gmail.com> writes:
>>>> 2009/7/30 Robert Haas <robertmhaas@gmail.com>:
>>>>> On Thu, Jul 30, 2009 at 10:35 AM, Brendan Jurd<direvus@gmail.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
>


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: mixed, named notation support
Next
From: Andres Freund
Date:
Subject: Re: machine-readable explain output v4