Обсуждение: to_timestamp not stable if date string shorter than template

Поиск
Список
Период
Сортировка

to_timestamp not stable if date string shorter than template

От
"Stacy White"
Дата:
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'.

Re: to_timestamp not stable if date string shorter than template

От
Tom Lane
Дата:
"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

Re: to_timestamp not stable if date string shorter than

От
Stephan Szabo
Дата:
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)

Re: to_timestamp not stable if date string shorter than

От
Stephan Szabo
Дата:
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.

Re: to_timestamp not stable if date string shorter than

От
Stephan Szabo
Дата:
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?

Re: to_timestamp not stable if date string shorter than

От
Tom Lane
Дата:
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

Re: to_timestamp not stable if date string shorter than

От
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

Re: to_timestamp not stable if date string shorter than

От
Stephan Szabo
Дата:
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.

Re: to_timestamp not stable if date string shorter than

От
Karel Zak
Дата:
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/

Re: to_timestamp not stable if date string shorter than template

От
"Mendola Gaetano"
Дата:
----- 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

Чтобы сделать работу с сайтом удобнее, мы используем cookie и аналитический сервис «Яндекс.Метрика». Продолжая пользоваться сайтом, вы соглашаетесь с их использованием.