Returned due to virus; was: Re: Wicked screensaver

See the attached file for details
From pgsql-bugs-owner(at)postgresql(dot)org Tue Sep 2 22:51:19 2003
X-Original-To: pgsql-bugs-postgresql(dot)org(at)localhost(dot)postgresql(dot)org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id 55BE9D1B8B3
for <pgsql-bugs-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>; Wed, 3 Sep 2003 01:51:18 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 27016-08
for <pgsql-bugs-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>;
Tue, 2 Sep 2003 22:51:11 -0300 (ADT)
Received: from megazone.bigpanda.com (45.mufb.snfc.sffca01r18.dsl.att.net [12.103.249.45])
by svr1.postgresql.org (Postfix) with ESMTP id 94A64D1B8AE
for <pgsql-bugs(at)postgresql(dot)org>; Tue, 2 Sep 2003 22:51:06 -0300 (ADT)
Received: by megazone.bigpanda.com (Postfix, from userid 1001)
id 071BED693; Tue, 2 Sep 2003 18:51:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by megazone.bigpanda.com (Postfix) with ESMTP
id C6A385C02; Tue, 2 Sep 2003 18:51:08 -0700 (PDT)
Date: Tue, 2 Sep 2003 18:51:07 -0700 (PDT)
From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stacy White <harsh(at)computer(dot)org>, <pgsql-bugs(at)postgresql(dot)org>,
Aaron Harsh <ajh(at)rentrak(dot)com>
Subject: Re: to_timestamp not stable if date string shorter than
In-Reply-To: <20030902163331(dot)M53013-100000(at)megazone(dot)bigpanda(dot)com>
Message-ID: <20030902184240(dot)T56775-100000(at)megazone(dot)bigpanda(dot)com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200309/22
X-Sequence-Number: 6653

On Tue, 2 Sep 2003, Stephan Szabo wrote:

>
> On Tue, 2 Sep 2003, Tom Lane wrote:
>
> > "Stacy White" <harsh(at)computer(dot)org> writes:
> > > to_timestamp appears to pick up the time-of-day from the previous call's
> > > return value if a date string has no time component. For example:
> >
> > Weird. I do not see that here, on either 7.3.4 or current sources.
> > Can anyone else reproduce it?
> >
> > For the record, I get:
> >
> > regression=# select to_timestamp('2003-06-01', 'YYYY-MM-DD HH24:MI:SS') ;
> > to_timestamp
> > ------------------------
> > 2003-06-01 00:00:00-04
> > (1 row)
> >
> > regression=# select to_timestamp('2003-06-02 12:13:14', 'YYYY-MM-DD HH24:MI:SS') ;
> > to_timestamp
> > ------------------------
> > 2003-06-02 12:13:14-04
> > (1 row)
> >
> > regression=# select to_timestamp('2003-06-01', 'YYYY-MM-DD HH24:MI:SS') ;
> > to_timestamp
> > ------------------------
> > 2003-06-01 00:00:00-04
> > (1 row)
>
> I seem to get the incorrect behavior on my 7.4 beta 1 system. The
> behavior on my machine is really wierd in fact even without times
> involved:
>
> test=# select to_timestamp('2003-06-04', 'YYYY-MM-DD HH24:MI:SS') ;
> to_timestamp
> ------------------------
> 2003-06-04 00:00:00-07
> (1 row)
>
> test=# select to_timestamp('2003-06', 'YYYY-MM-DD HH24:MI:SS') ;
> to_timestamp
> ------------------------
> 2003-06-04 00:00:00-07
> (1 row)
>
> test=# select to_timestamp('2003', 'YYYY-MM-DD HH24:MI:SS') ;
> to_timestamp
> ------------------------
> 2003-01-01 00:04:00-08
> (1 row)
>
> test=# select to_timestamp('2003-06', 'YYYY-MM-DD HH24:MI:SS') ;
> to_timestamp
> ------------------------
> 2003-06-04 00:00:00-07
> (1 row)
>
> test=# select to_timestamp('2003-07', 'YYYY-MM-DD HH24:MI:SS') ;
> to_timestamp
> ------------------------
> 2003-07-04 00:00:00-07
> (1 row)

From my beta1 machine it looks to me that to_timestamp is willing to read
off the end of the input string sometimes:

Breakpoint 3, DCH_processor (node=0x82d8da0, inout=0x8347860 "2003-06",
flag=2, data=0xbfffd080) at formatting.c:1302
1302 len = n->key->action(n->key->id, s,
n->suffix, flag, n, data);
(gdb) print s
$3 = 0x8347860 "2003-06"
(gdb) cont
Continuing.

Breakpoint 3, DCH_processor (node=0x82d8da0, inout=0x8347860 "2003-06",
flag=2, data=0xbfffd080) at formatting.c:1302
1302 len = n->key->action(n->key->id, s,
n->suffix, flag, n, data);
(gdb) print s
$4 = 0x8347865 "06"
(gdb) cont
Continuing.

** All of a sudden at this following breakpoint s has more text in it and
is past the \0 which would be at 0x8347867 AFAICS. ***

Breakpoint 3, DCH_processor (node=0x82d8da0, inout=0x8347860 "2003-06",
flag=2, data=0xbfffd080) at formatting.c:1302
1302 len = n->key->action(n->key->id, s,
n->suffix, flag, n, data);
(gdb) print s
$5 = 0x8347868 "04 02:02:02"
(gdb) cont
Continuing.

Breakpoint 3, DCH_processor (node=0x82d8da0, inout=0x8347860 "2003-06",
flag=2, data=0xbfffd080) at formatting.c:1302
1302 len = n->key->action(n->key->id, s,
n->suffix, flag, n, data);
(gdb) print s
$6 = 0x834786b "02:02:02"
(gdb)

---
I don't entirely understand all of what that code is doing, but I think
there's something in there that needs to get fixed.