Re: WIP: to_char, support for EEEE format
От | Robert Haas |
---|---|
Тема | Re: WIP: to_char, support for EEEE format |
Дата | |
Msg-id | 603c8f070908020840h67bf71d7rdb3447a673d71b9f@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: to_char, support for EEEE format (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: WIP: to_char, support for EEEE format
|
Список | pgsql-hackers |
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. ...Robert
В списке pgsql-hackers по дате отправления: