Re: Invalid to_date patterns (was: [PATCHES] [GENERAL] ISO week dates)
От | Brendan Jurd |
---|---|
Тема | Re: Invalid to_date patterns (was: [PATCHES] [GENERAL] ISO week dates) |
Дата | |
Msg-id | 37ed240d0702171924t43f7f0eeue968d0f38d73c75@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Invalid to_date patterns (was: [PATCHES] [GENERAL] ISO week dates) (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: Invalid to_date patterns (was: [PATCHES] [GENERAL] ISO week dates)
|
Список | pgsql-hackers |
On 2/17/07, Martijn van Oosterhout <kleptog@svana.org> wrote: > On Sat, Feb 17, 2007 at 02:41:32PM +1100, Brendan Jurd wrote: > > My gut reaction at first was to go with the former approach. It's > > programmatically more simple, and it's easier to explain in > > documentation/error messages. But then it occurred to me that one of > > the use cases for to_date is slurping date information out of textual > > reports which may contain redundant date information. If a user > > wanted to parse something like "2007-02-17 Q1", he would probably try > > 'YYYY-MM-DD "Q"Q', even though this pattern is logically > > over-constraining. Would it be fair to throw an error in such a case? > > If that's the use case, it would seem to me reasonable to be able to > mark fields for parsing but to not use them in the final calculation, > like the * modifier for scanf in C. > > Other than that I'd follow whatever Oracle does, that seem to be the > trend with those functions. I just looked through the Oracle documentation, and it is conspicuously silent on the topic of invalid format patterns. Much like ours in fact. I like your suggestion of the pattern modifier. So if a user did try to format with 'YYYY-MM-DD "Q"Q', we would throw an error telling them that the pattern is over-constraining, and they can use this pattern modifier (* or whatever) to single out the non-normative fields. Anybody else want to weigh in on this?
В списке pgsql-hackers по дате отправления: