On Fri, Sep 26, 2008 at 8:05 AM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 25, 2008 at 10:22 AM, Tom Lane <[EMAIL PROTECTED]> 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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
