Thread: to_timestamp not stable if date string shorter than template
Architecture: Intel Pentium
Operating System: Redhat 7.2 (Linux 2.4.17)
PostgreSQL version: PostgreSQL-7.3.4
Compiler used: gcc 3.01
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:
# select to_timestamp('2003-06-01', 'YYYY-MM-DD HH24:MI:SS') ;
to_timestamp
------------------------
2003-06-01 00:00:00-07
(1 row)
# select to_timestamp('2003-06-02 12:13:14', 'YYYY-MM-DD HH24:MI:SS') ;
to_timestamp
------------------------
2003-06-02 12:13:14-07
(1 row)
# select to_timestamp('2003-06-01', 'YYYY-MM-DD HH24:MI:SS') ;
to_timestamp
------------------------
2003-06-01 12:13:14-07
(1 row)
I suppose the proper behavior in this situation is debatable, but it seems
that the function should be stable.
FWIW, Oracle's behavior in this case (with 'to_date') is to return
'2003-06-01 00:00:00'.
"Stacy White" <harsh@computer.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)
regards, tom lane
On Tue, 2 Sep 2003, Tom Lane wrote:
> "Stacy White" <harsh@computer.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)
On Tue, 2 Sep 2003, Stephan Szabo wrote:
>
> On Tue, 2 Sep 2003, Tom Lane wrote:
>
> > "Stacy White" <harsh@computer.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.
On Tue, 2 Sep 2003, Stephan Szabo wrote:
> On Tue, 2 Sep 2003, Stephan Szabo wrote:
>
> >
> > On Tue, 2 Sep 2003, Tom Lane wrote:
> >
> > > "Stacy White" <harsh@computer.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?
> > >
>
> >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.
Replying to myself again:
In DCH_processor (formatting.c), it doesn't seem to stop if it's in the
middle of processing nodes but runs off the inout string, should the for
loop be something like:
for (n=node,s=inout;n->type!=NODE_TYPE_END && *s!='\0';++n,++s) {
and get rid of the ++s at the bottom of the loop for safety?
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> 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.
Oh-ho, this is interesting:
Build CVS tip on RHL 8.0 with --enable-cassert: no bug.
Build CVS tip on RHL 8.0 without --enable-cassert: bug.
Digging ...
regards, tom lane
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> Replying to myself again:
> In DCH_processor (formatting.c), it doesn't seem to stop if it's in the
> middle of processing nodes but runs off the inout string, should the for
> loop be something like:
> for (n=node,s=inout;n->type!=NODE_TYPE_END && *s!='\0';++n,++s) {
> and get rid of the ++s at the bottom of the loop for safety?
That wouldn't change the behavior, would it?
The code is definitely running off the end of the input string. I am
tempted to suggest that the "++s" at the bottom of the loop should
become
if (*s)
++s;
but I'm not sure enough of the intentions of this code to recommend
that as a full fix. Karel, the ball's in your court ...
regards, tom lane
On Wed, 3 Sep 2003, Tom Lane wrote:
> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> > Replying to myself again:
> > In DCH_processor (formatting.c), it doesn't seem to stop if it's in the
> > middle of processing nodes but runs off the inout string, should the for
> > loop be something like:
> > for (n=node,s=inout;n->type!=NODE_TYPE_END && *s!='\0';++n,++s) {
> > and get rid of the ++s at the bottom of the loop for safety?
>
> That wouldn't change the behavior, would it?
It would I believe, as soon as it reached a \0 it'd stop the loop, but
checking *s is probably the wrong thing to do when flag==TO_CHAR, so I
think that bailing to Karel is probably the right choice.
On Wed, Sep 03, 2003 at 12:03:59AM -0400, Tom Lane wrote:
> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> > 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.
>
> Oh-ho, this is interesting:
>
> Build CVS tip on RHL 8.0 with --enable-cassert: no bug.
>
> Build CVS tip on RHL 8.0 without --enable-cassert: bug.
It's seems like typical leak... I will try fix it today.
Karel
--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
Newsgroups: comp.databases.postgresql.bugs
Sent: Wednesday, September 03, 2003 1:05 AM
Subject: Re: to_timestamp not stable if date string shorter than template
> "Stacy White" <harsh@computer.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?
I get on Postgres 7.3.3:
test=# select to_timestamp('2003-06-01', 'YYYY-MM-DD HH24:MI:SS') ;
to_timestamp
------------------------
2003-06-01 00:08:00+02
(1 row)
test=# select to_timestamp('2003-06-02 12:13:14', 'YYYY-MM-DD HH24:MI:SS') ;
to_timestamp
------------------------
2003-06-02 12:13:14+02
(1 row)
test=# select to_timestamp('2003-06-01', 'YYYY-MM-DD HH24:MI:SS') ;
to_timestamp
------------------------
2003-06-01 00:08:00+02
(1 row)
Why 00:08:00+02 ?
Regards
Gaetano Mendola