Thread: 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@mit.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@sss.pgh.pa.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@mit.edu> writes:
> On Wed, Jul 29, 2009 at 5:15 PM, Tom Lane<tgl@sss.pgh.pa.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