"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On Sat, Sep 27, 2008 at 12:11 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Agreed on separating the message issue. What I wanted to know was
>> whether there are similar bugs elsewhere in to_timestamp, or whether
>> you're pretty sure this is the only occ
On Sat, Sep 27, 2008 at 12:11 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Agreed on separating the message issue. What I wanted to know was
> whether there are similar bugs elsewhere in to_timestamp, or whether
> you're pretty sure this is the only occurrence of the coding pattern?
I'm pretty sur
On Fri, Sep 26, 2008 at 8:11 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>> 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 of
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> 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?
Agreed on separati
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 throu
On Thu, Sep 25, 2008 at 4:05 PM, 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 throu
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 t
"Joshua Tolley" <[EMAIL PROTECTED]> 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:
regressi
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.
[EMAIL PROTECTED]:~/devel/raybo$ psql raybo -f test.sql
CREATE TABLE
INSERT 0 1
INSERT 0 1
psql:test.sql:21: ERROR: invalid AM/PM string
psql
