Re: Meridiem markers (was: [BUGS] Incorrect "invalid AM/PM string" error from to_timestamp) - Mailing list pgsql-hackers

From Alex Hunsaker
Subject Re: Meridiem markers (was: [BUGS] Incorrect "invalid AM/PM string" error from to_timestamp)
Date
Msg-id 34d269d40809261103j6d124444oac48e4c86c8b8cb@mail.gmail.com
Whole thread Raw
In response to Meridiem markers (was: [BUGS] Incorrect "invalid AM/PM string" error from to_timestamp)  ("Brendan Jurd" <direvus@gmail.com>)
Responses Re: Meridiem markers (was: [BUGS] Incorrect "invalid AM/PM string" error from to_timestamp)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Sep 26, 2008 at 11:25 AM, Brendan Jurd <direvus@gmail.com> wrote:
> One way to tidy this up would be to re-implement the meridiem markers
> using the seq_search functions, i.e., make it work like the day and
> month names.  This would make it easy to accept any flavour of marker,
> and the error messages thrown for bogus input would then be the same
> as those for bogus day and month names.

Yeah if we seq_search then it should be a pretty easy conversion. so +1

However that still leaves the original complaint around (at least IMHO):

select to_timestamp('AN', 'AM');
ERROR:  invalid AM/PM string

select to_timestamp('11:47 PM 27 Sep a2008', 'HH:MI PM DD Mon YYYY');
ERROR: invalid value for "YYYY" in source string


Now arguably most to_timestamp calls are going to be short so i can
easily look for the YYYY in my string and see what I did wrong (and
DETAIL: provides Value must be an integer in the second case)... So
really maybe thats good enough I dunno... Personally I find the output
of my dumb patch to be better than both above:

select to_timestamp('AN', 'AM');
ERROR: invalid AM/PM string for 'AN'

And we could improve that by only showing node->key->len chars.  And
make that work for both AM/PM and the others YYYY etc

Then again maybe its not worth it?


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: lock contention on parallel COPY ?
Next
From: Stefan Kaltenbrunner
Date:
Subject: Re: lock contention on parallel COPY ?