Re: Incorrect "invalid AM/PM string" error from to_timestamp
От | Brendan Jurd |
---|---|
Тема | Re: Incorrect "invalid AM/PM string" error from to_timestamp |
Дата | |
Msg-id | 37ed240d0809260704m2a642230sc4280e583d3cbff1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Incorrect "invalid AM/PM string" error from to_timestamp ("Alex Hunsaker" <badalex@gmail.com>) |
Ответы |
Re: Incorrect "invalid AM/PM string" error from to_timestamp
|
Список | pgsql-bugs |
On Fri, Sep 26, 2008 at 8:05 AM, Alex Hunsaker <badalex@gmail.com> wrote: > On Thu, Sep 25, 2008 at 10:22 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> A likely bet is that this is caused by use of uninitialized memory, >> which happens to have garbage rather than zeroes in it the second >> time through. > > Yep both DCH_MC and DCH_US were going past the end of the string > because they still added the length of the string where > from_char_parse_int_len takes care of that for us now... > Nice catch. I think your patch does the right thing here by pulling "len" out of those lines which advance the pointer after calling from_char_parse_int_len. > The attach patch fixes it and tries to improve the "invalid AM/PM > string" a bit by showing the string. > Not so sure about this part ... because it just spits out the variable "s", it will show whatever is left in the string at the time the macro is called. That works okay when the AM/PM string is at the end of the pattern, but ends up looking pretty weird otherwise: postgres=# select to_timestamp('11:47 Pm 26 Sep 2008', 'HH:MI AM DD Mon YYYY'); ERROR: invalid AM/PM string for 'Pm 26 Sep 2008' I have some thoughts on this and other issues surrounding AM/PM, but perhaps they are better reserved for a separate thread. Might I suggest we apply Alex's bugfix and hold off on the message changes pending further discussion? Cheers, BJ
В списке pgsql-bugs по дате отправления: