[HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] date_part()/EXTRACT(second) behaviour with time data type
Gregory Stark st...@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 / 100.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] date_part()/EXTRACT(second) behaviour with time data type
On Wed, Jul 29, 2009 at 5:15 PM, Tom Lanet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] date_part()/EXTRACT(second) behaviour with time data type
Greg Stark st...@mit.edu writes: On Wed, Jul 29, 2009 at 5:15 PM, Tom Lanet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
