Re: Invalid to_date patterns (was: [PATCHES] [GENERAL] ISO week dates)

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Brendan Jurd <direvus(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Guillaume Lelarge <guillaume(at)lelarge(dot)info>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Invalid to_date patterns (was: [PATCHES] [GENERAL] ISO week dates)
Date: 2007-02-17 12:36:26
Message-ID: 20070217123626.GA17174@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Karsten Hilbert 2007-02-17 14:15:25 Re: [ANNOUNCE] Advisory on possibly insecure security definer functions
Previous Message Lukas Kahwe Smith 2007-02-17 12:35:08 Re: wishlist items ..