Re: [BUGS] to_timestamp not stable if date string shorter than

#1

On Tue, 2 Sep 2003, Stephan Szabo wrote:

Quote:

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.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

#2

Stephan Szabo <sszabo (AT) megazone (DOT) bigpanda.com> writes:

Quote:

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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

#3

Stephan Szabo <sszabo (AT) megazone (DOT) bigpanda.com> writes:

Quote:

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

#4

On Wed, 3 Sep 2003, Tom Lane wrote:

Quote:

Stephan Szabo <sszabo (AT) megazone (DOT) 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.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

#5

On Wed, Sep 03, 2003 at 12:03:59AM -0400, Tom Lane wrote:

Quote:

Stephan Szabo <sszabo (AT) megazone (DOT) 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 (AT) zf (DOT) jcu.cz>
http://home.zf.jcu.cz/~zakkr/

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Re: [BUGS] to_timestamp not stable if date string shorter than

mailing.database.pgsql-bugs mailing.database.pgsql-bugs

Re: [BUGS] to_timestamp not stable if date string shorter than - 09-02-2003 , 08:51 PM

Re: [BUGS] to_timestamp not stable if date string shorter than - 09-02-2003 , 11:04 PM

Re: [BUGS] to_timestamp not stable if date string shorter than - 09-02-2003 , 11:16 PM

Re: [BUGS] to_timestamp not stable if date string shorter than - 09-02-2003 , 11:33 PM

Re: [BUGS] to_timestamp not stable if date string shorter than - 09-03-2003 , 02:32 AM