From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Joshua Tolley" <eggyknap(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org, "Brendan Jurd" <direvus(at)gmail(dot)com> |
Subject: | Re: Incorrect "invalid AM/PM string" error from to_timestamp |
Date: | 2008-09-25 16:22:31 |
Message-ID: | 8148.1222359751@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Joshua Tolley" <eggyknap(at)gmail(dot)com> writes:
> I'm running this on 8.4devel built from CVS HEAD as of 9:44 AM Moutain
> Daylight time today, on a 32-bit Ubuntu 7.04 box. This is a completely
> new database.
Ugh, apparently there's some state-dependent bug in the recent
to_timestamp fixes:
regression=# \c -
psql (8.4devel)
You are now connected to database "regression".
regression=# select to_timestamp('21-SEP-08 08.15.42.950620 PM', 'DD-MON-YY HH.MI.SS.US AM');
to_timestamp
------------------------------
2008-09-21 08:15:42.95062-04
(1 row)
regression=# select to_timestamp('21-SEP-08 08.15.42.950620 PM', 'DD-MON-YY HH.MI.SS.US AM');
ERROR: invalid AM/PM string
regression=#
Yes, those are the same command. The error is repeatable on subsequent
executions in the same session.
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.
Brendan, do you have time to look into this?
BTW, the error message is pretty unhelpful: ISTM it really ought to show
the value it's complaining of.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-09-25 17:22:20 | Re: BUG #4437: Breaking referential integrity with a trigger |
Previous Message | Tim Leppard | 2008-09-25 16:15:43 | BUG #4437: Breaking referential integrity with a trigger |