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?
