Re: date_part()/EXTRACT(second) behaviour with time data type

I think we broke date_part for extracting seconds from time arguments. It
appears we leave out the milliseconds whereas we don't for timestamp
arguments. This was not the case in 8.3 where we included the milliseconds for
both data types.

Unless this is intentional? I know we wacked around both the meaning of SECOND
for intervals and the code for date_part in a lot of ways. But I don't see why
it would be different for time versus timestamp.

postgres=# select extract(second from now()::time with time zone);
date_part
-----------
27
(1 row)

postgres=# select extract(second from now()::time without time zone);
date_part
-----------
27
(1 row)

postgres=# select extract(second from now()::timestamp with time zone);
date_part
-----------
27.782458
(1 row)

postgres=# select extract(second from now()::timestamp without time zone);
date_part
-----------
27.782458
(1 row)

--
Gregory Stark
http://mit.edu/~gsstark/resume.pdf

Gregory Stark <stark(at)mit(dot)edu> writes:
> I think we broke date_part for extracting seconds from time arguments. It
> appears we leave out the milliseconds whereas we don't for timestamp
> arguments. This was not the case in 8.3 where we included the milliseconds for
> both data types.

It's not new. This appears to be a difference between the integer and
float timestamp code paths, and I'd say it's probably a thinko:

case DTK_SECOND:
#ifdef HAVE_INT64_TIMESTAMP
result = tm->tm_sec + fsec / USECS_PER_SEC;
#else
result = tm->tm_sec + fsec;
#endif
break;

In the integer case, fsec is an integer and so the division loses the
fraction. timestamptz_part does this instead:

case DTK_SECOND:
#ifdef HAVE_INT64_TIMESTAMP
result = tm->tm_sec + fsec / 1000000.0;
#else
result = tm->tm_sec + fsec;
#endif
break;

I agree that we should change it, but should we back-patch it, and if so
how far?

regards, tom lane

On Wed, Jul 29, 2009 at 5:15 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I agree that we should change it, but should we back-patch it, and if so
> how far?
>

Well at least to 8.4 so someone who has just always been using
downloaded binaries or binaries compiled with the default
configuration continues to get the same behaviour.

My inclination would be to backpatch it further back. But I'm not 100%
sure either.

--
greg
http://mit.edu/~gsstark/resume.pdf

Greg Stark <stark(at)mit(dot)edu> writes:
> On Wed, Jul 29, 2009 at 5:15 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I agree that we should change it, but should we back-patch it, and if so
>> how far?

> Well at least to 8.4 so someone who has just always been using
> downloaded binaries or binaries compiled with the default
> configuration continues to get the same behaviour.

> My inclination would be to backpatch it further back. But I'm not 100%
> sure either.

Given the lack of prior complaints, I'm thinking just to 8.4 is a good
compromise. Any objections out there?

regards, tom lane