2000-09-12 07:42:20 +02:00
|
|
|
--
|
|
|
|
-- DATE
|
|
|
|
--
|
|
|
|
CREATE TABLE DATE_TBL (f1 date);
|
|
|
|
INSERT INTO DATE_TBL VALUES ('1957-04-09');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('1957-06-13');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('1996-02-28');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('1996-02-29');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('1996-03-01');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('1996-03-02');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('1997-02-28');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('1997-02-29');
|
2003-08-28 01:29:29 +02:00
|
|
|
ERROR: date/time field value out of range: "1997-02-29"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: INSERT INTO DATE_TBL VALUES ('1997-02-29');
|
|
|
|
^
|
2000-09-12 07:42:20 +02:00
|
|
|
INSERT INTO DATE_TBL VALUES ('1997-03-01');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('1997-03-02');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('2000-04-01');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('2000-04-02');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('2000-04-03');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('2038-04-08');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('2039-04-09');
|
|
|
|
INSERT INTO DATE_TBL VALUES ('2040-04-10');
|
2020-09-10 14:52:36 +02:00
|
|
|
INSERT INTO DATE_TBL VALUES ('2040-04-10 BC');
|
|
|
|
SELECT f1 FROM DATE_TBL;
|
|
|
|
f1
|
|
|
|
---------------
|
2000-09-12 07:42:20 +02:00
|
|
|
04-09-1957
|
|
|
|
06-13-1957
|
|
|
|
02-28-1996
|
|
|
|
02-29-1996
|
|
|
|
03-01-1996
|
|
|
|
03-02-1996
|
|
|
|
02-28-1997
|
|
|
|
03-01-1997
|
|
|
|
03-02-1997
|
|
|
|
04-01-2000
|
|
|
|
04-02-2000
|
|
|
|
04-03-2000
|
|
|
|
04-08-2038
|
|
|
|
04-09-2039
|
|
|
|
04-10-2040
|
2020-09-10 14:52:36 +02:00
|
|
|
04-10-2040 BC
|
|
|
|
(16 rows)
|
2000-09-12 07:42:20 +02:00
|
|
|
|
2020-09-10 14:52:36 +02:00
|
|
|
SELECT f1 FROM DATE_TBL WHERE f1 < '2000-01-01';
|
|
|
|
f1
|
|
|
|
---------------
|
2000-09-12 07:42:20 +02:00
|
|
|
04-09-1957
|
|
|
|
06-13-1957
|
|
|
|
02-28-1996
|
|
|
|
02-29-1996
|
|
|
|
03-01-1996
|
|
|
|
03-02-1996
|
|
|
|
02-28-1997
|
|
|
|
03-01-1997
|
|
|
|
03-02-1997
|
2020-09-10 14:52:36 +02:00
|
|
|
04-10-2040 BC
|
|
|
|
(10 rows)
|
2000-09-12 07:42:20 +02:00
|
|
|
|
2020-09-10 14:52:36 +02:00
|
|
|
SELECT f1 FROM DATE_TBL
|
2000-09-12 07:42:20 +02:00
|
|
|
WHERE f1 BETWEEN '2000-01-01' AND '2001-01-01';
|
2020-09-10 14:52:36 +02:00
|
|
|
f1
|
2000-09-12 07:42:20 +02:00
|
|
|
------------
|
|
|
|
04-01-2000
|
|
|
|
04-02-2000
|
|
|
|
04-03-2000
|
|
|
|
(3 rows)
|
|
|
|
|
2003-11-16 21:29:16 +01:00
|
|
|
--
|
|
|
|
-- Check all the documented input formats
|
|
|
|
--
|
|
|
|
SET datestyle TO iso; -- display results in ISO
|
|
|
|
SET datestyle TO ymd;
|
|
|
|
SELECT date 'January 8, 1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999-01-08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999-01-18';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-18
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1/8/1999';
|
|
|
|
ERROR: date/time field value out of range: "1/8/1999"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '1/8/1999';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '1/18/1999';
|
|
|
|
ERROR: date/time field value out of range: "1/18/1999"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '1/18/1999';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '18/1/1999';
|
|
|
|
ERROR: date/time field value out of range: "18/1/1999"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '18/1/1999';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '01/02/03';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
2001-02-03
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '19990108';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '990108';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999.008';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'J2451187';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'January 8, 99 BC';
|
|
|
|
ERROR: date/time field value out of range: "January 8, 99 BC"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date 'January 8, 99 BC';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '99-Jan-08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999-Jan-08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08-Jan-99';
|
|
|
|
ERROR: date/time field value out of range: "08-Jan-99"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '08-Jan-99';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '08-Jan-1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'Jan-08-99';
|
|
|
|
ERROR: date/time field value out of range: "Jan-08-99"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date 'Jan-08-99';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date 'Jan-08-1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99-08-Jan';
|
|
|
|
ERROR: invalid input syntax for type date: "99-08-Jan"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99-08-Jan';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
SELECT date '1999-08-Jan';
|
|
|
|
ERROR: invalid input syntax for type date: "1999-08-Jan"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '1999-08-Jan';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
SELECT date '99 Jan 08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999 Jan 08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08 Jan 99';
|
|
|
|
ERROR: date/time field value out of range: "08 Jan 99"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '08 Jan 99';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '08 Jan 1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'Jan 08 99';
|
|
|
|
ERROR: date/time field value out of range: "Jan 08 99"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date 'Jan 08 99';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date 'Jan 08 1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99 08 Jan';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999 08 Jan';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99-01-08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999-01-08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08-01-99';
|
|
|
|
ERROR: date/time field value out of range: "08-01-99"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '08-01-99';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '08-01-1999';
|
|
|
|
ERROR: date/time field value out of range: "08-01-1999"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '08-01-1999';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '01-08-99';
|
|
|
|
ERROR: date/time field value out of range: "01-08-99"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '01-08-99';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '01-08-1999';
|
|
|
|
ERROR: date/time field value out of range: "01-08-1999"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '01-08-1999';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '99-08-01';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999-08-01';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99 01 08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999 01 08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08 01 99';
|
|
|
|
ERROR: date/time field value out of range: "08 01 99"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '08 01 99';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '08 01 1999';
|
|
|
|
ERROR: date/time field value out of range: "08 01 1999"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '08 01 1999';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '01 08 99';
|
|
|
|
ERROR: date/time field value out of range: "01 08 99"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '01 08 99';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '01 08 1999';
|
|
|
|
ERROR: date/time field value out of range: "01 08 1999"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '01 08 1999';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '99 08 01';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999 08 01';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SET datestyle TO dmy;
|
|
|
|
SELECT date 'January 8, 1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999-01-08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999-01-18';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-18
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1/8/1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1/18/1999';
|
|
|
|
ERROR: date/time field value out of range: "1/18/1999"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '1/18/1999';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '18/1/1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-18
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '01/02/03';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
2003-02-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '19990108';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '990108';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999.008';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'J2451187';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'January 8, 99 BC';
|
|
|
|
date
|
|
|
|
---------------
|
|
|
|
0099-01-08 BC
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99-Jan-08';
|
|
|
|
ERROR: date/time field value out of range: "99-Jan-08"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99-Jan-08';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '1999-Jan-08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08-Jan-99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08-Jan-1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'Jan-08-99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'Jan-08-1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99-08-Jan';
|
|
|
|
ERROR: invalid input syntax for type date: "99-08-Jan"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99-08-Jan';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
SELECT date '1999-08-Jan';
|
|
|
|
ERROR: invalid input syntax for type date: "1999-08-Jan"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '1999-08-Jan';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
SELECT date '99 Jan 08';
|
|
|
|
ERROR: date/time field value out of range: "99 Jan 08"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99 Jan 08';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '1999 Jan 08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08 Jan 99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08 Jan 1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'Jan 08 99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'Jan 08 1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99 08 Jan';
|
|
|
|
ERROR: invalid input syntax for type date: "99 08 Jan"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99 08 Jan';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
SELECT date '1999 08 Jan';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99-01-08';
|
|
|
|
ERROR: date/time field value out of range: "99-01-08"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99-01-08';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '1999-01-08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08-01-99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08-01-1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '01-08-99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '01-08-1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99-08-01';
|
|
|
|
ERROR: date/time field value out of range: "99-08-01"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99-08-01';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '1999-08-01';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99 01 08';
|
|
|
|
ERROR: date/time field value out of range: "99 01 08"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99 01 08';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '1999 01 08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08 01 99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08 01 1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '01 08 99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '01 08 1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99 08 01';
|
|
|
|
ERROR: date/time field value out of range: "99 08 01"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99 08 01';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '1999 08 01';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SET datestyle TO mdy;
|
|
|
|
SELECT date 'January 8, 1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999-01-08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999-01-18';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-18
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1/8/1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1/18/1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-18
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '18/1/1999';
|
|
|
|
ERROR: date/time field value out of range: "18/1/1999"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '18/1/1999';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '01/02/03';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
2003-01-02
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '19990108';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '990108';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '1999.008';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'J2451187';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'January 8, 99 BC';
|
|
|
|
date
|
|
|
|
---------------
|
|
|
|
0099-01-08 BC
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99-Jan-08';
|
|
|
|
ERROR: date/time field value out of range: "99-Jan-08"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99-Jan-08';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '1999-Jan-08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08-Jan-99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08-Jan-1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'Jan-08-99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'Jan-08-1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99-08-Jan';
|
|
|
|
ERROR: invalid input syntax for type date: "99-08-Jan"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99-08-Jan';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
SELECT date '1999-08-Jan';
|
|
|
|
ERROR: invalid input syntax for type date: "1999-08-Jan"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '1999-08-Jan';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
SELECT date '99 Jan 08';
|
|
|
|
ERROR: invalid input syntax for type date: "99 Jan 08"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99 Jan 08';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
SELECT date '1999 Jan 08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08 Jan 99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08 Jan 1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'Jan 08 99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'Jan 08 1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99 08 Jan';
|
|
|
|
ERROR: invalid input syntax for type date: "99 08 Jan"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99 08 Jan';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
SELECT date '1999 08 Jan';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99-01-08';
|
|
|
|
ERROR: date/time field value out of range: "99-01-08"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99-01-08';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '1999-01-08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08-01-99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08-01-1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '01-08-99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '01-08-1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99-08-01';
|
|
|
|
ERROR: date/time field value out of range: "99-08-01"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99-08-01';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '1999-08-01';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99 01 08';
|
|
|
|
ERROR: date/time field value out of range: "99 01 08"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99 01 08';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '1999 01 08';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08 01 99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '08 01 1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '01 08 99';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '01 08 1999';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-01-08
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '99 08 01';
|
|
|
|
ERROR: date/time field value out of range: "99 08 01"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: SELECT date '99 08 01';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
HINT: Perhaps you need a different "datestyle" setting.
|
|
|
|
SELECT date '1999 08 01';
|
|
|
|
date
|
|
|
|
------------
|
|
|
|
1999-08-01
|
|
|
|
(1 row)
|
|
|
|
|
2016-03-17 00:09:04 +01:00
|
|
|
-- Check upper and lower limits of date range
|
|
|
|
SELECT date '4714-11-24 BC';
|
|
|
|
date
|
|
|
|
---------------
|
|
|
|
4714-11-24 BC
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '4714-11-23 BC'; -- out of range
|
|
|
|
ERROR: date out of range: "4714-11-23 BC"
|
|
|
|
LINE 1: SELECT date '4714-11-23 BC';
|
|
|
|
^
|
|
|
|
SELECT date '5874897-12-31';
|
|
|
|
date
|
|
|
|
---------------
|
|
|
|
5874897-12-31
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date '5874898-01-01'; -- out of range
|
|
|
|
ERROR: date out of range: "5874898-01-01"
|
|
|
|
LINE 1: SELECT date '5874898-01-01';
|
|
|
|
^
|
2003-11-16 21:29:16 +01:00
|
|
|
RESET datestyle;
|
2000-09-12 07:42:20 +02:00
|
|
|
--
|
|
|
|
-- Simple math
|
|
|
|
-- Leave most of it for the horology tests
|
|
|
|
--
|
|
|
|
SELECT f1 - date '2000-01-01' AS "Days From 2K" FROM DATE_TBL;
|
|
|
|
Days From 2K
|
|
|
|
--------------
|
|
|
|
-15607
|
|
|
|
-15542
|
|
|
|
-1403
|
|
|
|
-1402
|
|
|
|
-1401
|
|
|
|
-1400
|
|
|
|
-1037
|
|
|
|
-1036
|
|
|
|
-1035
|
|
|
|
91
|
|
|
|
92
|
|
|
|
93
|
|
|
|
13977
|
|
|
|
14343
|
|
|
|
14710
|
2020-09-10 14:52:36 +02:00
|
|
|
-1475115
|
|
|
|
(16 rows)
|
2000-09-12 07:42:20 +02:00
|
|
|
|
|
|
|
SELECT f1 - date 'epoch' AS "Days From Epoch" FROM DATE_TBL;
|
|
|
|
Days From Epoch
|
|
|
|
-----------------
|
|
|
|
-4650
|
|
|
|
-4585
|
|
|
|
9554
|
|
|
|
9555
|
|
|
|
9556
|
|
|
|
9557
|
|
|
|
9920
|
|
|
|
9921
|
|
|
|
9922
|
|
|
|
11048
|
|
|
|
11049
|
|
|
|
11050
|
|
|
|
24934
|
|
|
|
25300
|
|
|
|
25667
|
2020-09-10 14:52:36 +02:00
|
|
|
-1464158
|
|
|
|
(16 rows)
|
2000-09-12 07:42:20 +02:00
|
|
|
|
|
|
|
SELECT date 'yesterday' - date 'today' AS "One day";
|
|
|
|
One day
|
|
|
|
---------
|
|
|
|
-1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'today' - date 'tomorrow' AS "One day";
|
|
|
|
One day
|
|
|
|
---------
|
|
|
|
-1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'yesterday' - date 'tomorrow' AS "Two days";
|
|
|
|
Two days
|
|
|
|
----------
|
|
|
|
-2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'tomorrow' - date 'today' AS "One day";
|
|
|
|
One day
|
|
|
|
---------
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'today' - date 'yesterday' AS "One day";
|
|
|
|
One day
|
|
|
|
---------
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT date 'tomorrow' - date 'yesterday' AS "Two days";
|
|
|
|
Two days
|
|
|
|
----------
|
|
|
|
2
|
|
|
|
(1 row)
|
|
|
|
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
--
|
|
|
|
-- test extract!
|
2020-09-10 14:52:36 +02:00
|
|
|
--
|
|
|
|
SELECT f1 as "date",
|
|
|
|
date_part('year', f1) AS year,
|
|
|
|
date_part('month', f1) AS month,
|
|
|
|
date_part('day', f1) AS day,
|
|
|
|
date_part('quarter', f1) AS quarter,
|
|
|
|
date_part('decade', f1) AS decade,
|
|
|
|
date_part('century', f1) AS century,
|
|
|
|
date_part('millennium', f1) AS millennium,
|
|
|
|
date_part('isoyear', f1) AS isoyear,
|
|
|
|
date_part('week', f1) AS week,
|
|
|
|
date_part('dow', f1) AS dow,
|
|
|
|
date_part('isodow', f1) AS isodow,
|
|
|
|
date_part('doy', f1) AS doy,
|
|
|
|
date_part('julian', f1) AS julian,
|
|
|
|
date_part('epoch', f1) AS epoch
|
|
|
|
FROM date_tbl;
|
|
|
|
date | year | month | day | quarter | decade | century | millennium | isoyear | week | dow | isodow | doy | julian | epoch
|
|
|
|
---------------+-------+-------+-----+---------+--------+---------+------------+---------+------+-----+--------+-----+---------+---------------
|
|
|
|
04-09-1957 | 1957 | 4 | 9 | 2 | 195 | 20 | 2 | 1957 | 15 | 2 | 2 | 99 | 2435938 | -401760000
|
|
|
|
06-13-1957 | 1957 | 6 | 13 | 2 | 195 | 20 | 2 | 1957 | 24 | 4 | 4 | 164 | 2436003 | -396144000
|
|
|
|
02-28-1996 | 1996 | 2 | 28 | 1 | 199 | 20 | 2 | 1996 | 9 | 3 | 3 | 59 | 2450142 | 825465600
|
|
|
|
02-29-1996 | 1996 | 2 | 29 | 1 | 199 | 20 | 2 | 1996 | 9 | 4 | 4 | 60 | 2450143 | 825552000
|
|
|
|
03-01-1996 | 1996 | 3 | 1 | 1 | 199 | 20 | 2 | 1996 | 9 | 5 | 5 | 61 | 2450144 | 825638400
|
|
|
|
03-02-1996 | 1996 | 3 | 2 | 1 | 199 | 20 | 2 | 1996 | 9 | 6 | 6 | 62 | 2450145 | 825724800
|
|
|
|
02-28-1997 | 1997 | 2 | 28 | 1 | 199 | 20 | 2 | 1997 | 9 | 5 | 5 | 59 | 2450508 | 857088000
|
|
|
|
03-01-1997 | 1997 | 3 | 1 | 1 | 199 | 20 | 2 | 1997 | 9 | 6 | 6 | 60 | 2450509 | 857174400
|
|
|
|
03-02-1997 | 1997 | 3 | 2 | 1 | 199 | 20 | 2 | 1997 | 9 | 0 | 7 | 61 | 2450510 | 857260800
|
|
|
|
04-01-2000 | 2000 | 4 | 1 | 2 | 200 | 20 | 2 | 2000 | 13 | 6 | 6 | 92 | 2451636 | 954547200
|
|
|
|
04-02-2000 | 2000 | 4 | 2 | 2 | 200 | 20 | 2 | 2000 | 13 | 0 | 7 | 93 | 2451637 | 954633600
|
|
|
|
04-03-2000 | 2000 | 4 | 3 | 2 | 200 | 20 | 2 | 2000 | 14 | 1 | 1 | 94 | 2451638 | 954720000
|
|
|
|
04-08-2038 | 2038 | 4 | 8 | 2 | 203 | 21 | 3 | 2038 | 14 | 4 | 4 | 98 | 2465522 | 2154297600
|
|
|
|
04-09-2039 | 2039 | 4 | 9 | 2 | 203 | 21 | 3 | 2039 | 14 | 6 | 6 | 99 | 2465888 | 2185920000
|
|
|
|
04-10-2040 | 2040 | 4 | 10 | 2 | 204 | 21 | 3 | 2040 | 15 | 2 | 2 | 101 | 2466255 | 2217628800
|
|
|
|
04-10-2040 BC | -2040 | 4 | 10 | 2 | -204 | -21 | -3 | -2040 | 15 | 1 | 1 | 100 | 976430 | -126503251200
|
|
|
|
(16 rows)
|
|
|
|
|
2016-01-22 04:26:20 +01:00
|
|
|
--
|
|
|
|
-- epoch
|
|
|
|
--
|
|
|
|
SELECT EXTRACT(EPOCH FROM DATE '1970-01-01'); -- 0
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
0
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
--
|
|
|
|
-- century
|
|
|
|
--
|
|
|
|
SELECT EXTRACT(CENTURY FROM DATE '0101-12-31 BC'); -- -2
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
-2
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(CENTURY FROM DATE '0100-12-31 BC'); -- -1
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
-1
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(CENTURY FROM DATE '0001-12-31 BC'); -- -1
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
-1
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(CENTURY FROM DATE '0001-01-01'); -- 1
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
1
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(CENTURY FROM DATE '0001-01-01 AD'); -- 1
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
1
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(CENTURY FROM DATE '1900-12-31'); -- 19
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
19
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(CENTURY FROM DATE '1901-01-01'); -- 20
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
20
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(CENTURY FROM DATE '2000-12-31'); -- 20
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
20
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(CENTURY FROM DATE '2001-01-01'); -- 21
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
21
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(CENTURY FROM CURRENT_DATE)>=21 AS True; -- true
|
|
|
|
true
|
|
|
|
------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
--
|
|
|
|
-- millennium
|
|
|
|
--
|
|
|
|
SELECT EXTRACT(MILLENNIUM FROM DATE '0001-12-31 BC'); -- -1
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
-1
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(MILLENNIUM FROM DATE '0001-01-01 AD'); -- 1
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
1
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(MILLENNIUM FROM DATE '1000-12-31'); -- 1
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
1
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(MILLENNIUM FROM DATE '1001-01-01'); -- 2
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
2
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(MILLENNIUM FROM DATE '2000-12-31'); -- 2
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
2
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(MILLENNIUM FROM DATE '2001-01-01'); -- 3
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
3
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- next test to be fixed on the turn of the next millennium;-)
|
|
|
|
SELECT EXTRACT(MILLENNIUM FROM CURRENT_DATE); -- 3
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
3
|
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code
and the documentation, so that it conforms to the official definition.
If you do not agree with the official definition, please send your
complaint to "pope@vatican.org". I'm not responsible for them;-)
With the previous version, the centuries and millenniums had a wrong
number and started the wrong year. Moreover century number 0, which does
not exist in reality, lasted 200 years. Also, millennium number 0 lasted
2000 years.
If you want postgresql to have it's own definition of "century" and
"millennium" that does not conform to the one of the society, just give
them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
IMO, if someone may use the options, it means that postgresql is used for
historical data, so it make sense to have an historical definition. Also,
I just want to divide the year by 100 or 1000, I can do that quite easily.
BACKWARD INCOMPATIBLE CHANGE
Fabien Coelho - coelho@cri.ensmp.fr
2004-04-10 20:02:59 +02:00
|
|
|
(1 row)
|
|
|
|
|
> After all that about numbering centuries and millenia correctly,
> why does CVS tip still give me
>
> regression=# select extract(century from now());
> date_part
> -----------
> 20
> (1 row)
> [ ... looks in code ... ]
>
> Apparently it's because you fixed only timestamp_part, and not
> timestamptz_part. I'm not too sure about what timestamp_trunc or
> timestamptz_trunc should do, but they may be wrong as well.
Sigh... as usual, what is not tested does not work:-(
> Could we have a more complete patch?
Please find a submission attached. I hope it really fixes all decade,
century and millenium issues for extract and *_trunc functions on
interval
and other timestamp types. If someone could check that the results
are reasonnable, it would be great.
I indeed overlooked the fact that there were two functions. The patch
fixes the code so that both variants agree.
I added comments to interval extractions, because it relies on the C
division to have a negative remainder: -7/10 = 0 and remains -7.
As for *_trunc functions, I have chosen to put the first year of the
century or millennium: -100, 1, 101... 1001 2001 etc. Indeed, I don't
think it would make sense to put 2000 (last year of the 2nd millennium)
for rounding all years of the third millenium.
I also fixed the code so that all decades last 10 years and decade 199
means the 1990's.
I have added some tests that are relevant to deal with tricky cases. The
formula may be simplified, but all these cases must pass. Please keep
them.
Fabien Coelho
2004-08-20 05:45:14 +02:00
|
|
|
--
|
|
|
|
-- decade
|
|
|
|
--
|
|
|
|
SELECT EXTRACT(DECADE FROM DATE '1994-12-25'); -- 199
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
199
|
> After all that about numbering centuries and millenia correctly,
> why does CVS tip still give me
>
> regression=# select extract(century from now());
> date_part
> -----------
> 20
> (1 row)
> [ ... looks in code ... ]
>
> Apparently it's because you fixed only timestamp_part, and not
> timestamptz_part. I'm not too sure about what timestamp_trunc or
> timestamptz_trunc should do, but they may be wrong as well.
Sigh... as usual, what is not tested does not work:-(
> Could we have a more complete patch?
Please find a submission attached. I hope it really fixes all decade,
century and millenium issues for extract and *_trunc functions on
interval
and other timestamp types. If someone could check that the results
are reasonnable, it would be great.
I indeed overlooked the fact that there were two functions. The patch
fixes the code so that both variants agree.
I added comments to interval extractions, because it relies on the C
division to have a negative remainder: -7/10 = 0 and remains -7.
As for *_trunc functions, I have chosen to put the first year of the
century or millennium: -100, 1, 101... 1001 2001 etc. Indeed, I don't
think it would make sense to put 2000 (last year of the 2nd millennium)
for rounding all years of the third millenium.
I also fixed the code so that all decades last 10 years and decade 199
means the 1990's.
I have added some tests that are relevant to deal with tricky cases. The
formula may be simplified, but all these cases must pass. Please keep
them.
Fabien Coelho
2004-08-20 05:45:14 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DECADE FROM DATE '0010-01-01'); -- 1
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
1
|
> After all that about numbering centuries and millenia correctly,
> why does CVS tip still give me
>
> regression=# select extract(century from now());
> date_part
> -----------
> 20
> (1 row)
> [ ... looks in code ... ]
>
> Apparently it's because you fixed only timestamp_part, and not
> timestamptz_part. I'm not too sure about what timestamp_trunc or
> timestamptz_trunc should do, but they may be wrong as well.
Sigh... as usual, what is not tested does not work:-(
> Could we have a more complete patch?
Please find a submission attached. I hope it really fixes all decade,
century and millenium issues for extract and *_trunc functions on
interval
and other timestamp types. If someone could check that the results
are reasonnable, it would be great.
I indeed overlooked the fact that there were two functions. The patch
fixes the code so that both variants agree.
I added comments to interval extractions, because it relies on the C
division to have a negative remainder: -7/10 = 0 and remains -7.
As for *_trunc functions, I have chosen to put the first year of the
century or millennium: -100, 1, 101... 1001 2001 etc. Indeed, I don't
think it would make sense to put 2000 (last year of the 2nd millennium)
for rounding all years of the third millenium.
I also fixed the code so that all decades last 10 years and decade 199
means the 1990's.
I have added some tests that are relevant to deal with tricky cases. The
formula may be simplified, but all these cases must pass. Please keep
them.
Fabien Coelho
2004-08-20 05:45:14 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DECADE FROM DATE '0009-12-31'); -- 0
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
0
|
> After all that about numbering centuries and millenia correctly,
> why does CVS tip still give me
>
> regression=# select extract(century from now());
> date_part
> -----------
> 20
> (1 row)
> [ ... looks in code ... ]
>
> Apparently it's because you fixed only timestamp_part, and not
> timestamptz_part. I'm not too sure about what timestamp_trunc or
> timestamptz_trunc should do, but they may be wrong as well.
Sigh... as usual, what is not tested does not work:-(
> Could we have a more complete patch?
Please find a submission attached. I hope it really fixes all decade,
century and millenium issues for extract and *_trunc functions on
interval
and other timestamp types. If someone could check that the results
are reasonnable, it would be great.
I indeed overlooked the fact that there were two functions. The patch
fixes the code so that both variants agree.
I added comments to interval extractions, because it relies on the C
division to have a negative remainder: -7/10 = 0 and remains -7.
As for *_trunc functions, I have chosen to put the first year of the
century or millennium: -100, 1, 101... 1001 2001 etc. Indeed, I don't
think it would make sense to put 2000 (last year of the 2nd millennium)
for rounding all years of the third millenium.
I also fixed the code so that all decades last 10 years and decade 199
means the 1990's.
I have added some tests that are relevant to deal with tricky cases. The
formula may be simplified, but all these cases must pass. Please keep
them.
Fabien Coelho
2004-08-20 05:45:14 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DECADE FROM DATE '0001-01-01 BC'); -- 0
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
0
|
> After all that about numbering centuries and millenia correctly,
> why does CVS tip still give me
>
> regression=# select extract(century from now());
> date_part
> -----------
> 20
> (1 row)
> [ ... looks in code ... ]
>
> Apparently it's because you fixed only timestamp_part, and not
> timestamptz_part. I'm not too sure about what timestamp_trunc or
> timestamptz_trunc should do, but they may be wrong as well.
Sigh... as usual, what is not tested does not work:-(
> Could we have a more complete patch?
Please find a submission attached. I hope it really fixes all decade,
century and millenium issues for extract and *_trunc functions on
interval
and other timestamp types. If someone could check that the results
are reasonnable, it would be great.
I indeed overlooked the fact that there were two functions. The patch
fixes the code so that both variants agree.
I added comments to interval extractions, because it relies on the C
division to have a negative remainder: -7/10 = 0 and remains -7.
As for *_trunc functions, I have chosen to put the first year of the
century or millennium: -100, 1, 101... 1001 2001 etc. Indeed, I don't
think it would make sense to put 2000 (last year of the 2nd millennium)
for rounding all years of the third millenium.
I also fixed the code so that all decades last 10 years and decade 199
means the 1990's.
I have added some tests that are relevant to deal with tricky cases. The
formula may be simplified, but all these cases must pass. Please keep
them.
Fabien Coelho
2004-08-20 05:45:14 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DECADE FROM DATE '0002-12-31 BC'); -- -1
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
-1
|
> After all that about numbering centuries and millenia correctly,
> why does CVS tip still give me
>
> regression=# select extract(century from now());
> date_part
> -----------
> 20
> (1 row)
> [ ... looks in code ... ]
>
> Apparently it's because you fixed only timestamp_part, and not
> timestamptz_part. I'm not too sure about what timestamp_trunc or
> timestamptz_trunc should do, but they may be wrong as well.
Sigh... as usual, what is not tested does not work:-(
> Could we have a more complete patch?
Please find a submission attached. I hope it really fixes all decade,
century and millenium issues for extract and *_trunc functions on
interval
and other timestamp types. If someone could check that the results
are reasonnable, it would be great.
I indeed overlooked the fact that there were two functions. The patch
fixes the code so that both variants agree.
I added comments to interval extractions, because it relies on the C
division to have a negative remainder: -7/10 = 0 and remains -7.
As for *_trunc functions, I have chosen to put the first year of the
century or millennium: -100, 1, 101... 1001 2001 etc. Indeed, I don't
think it would make sense to put 2000 (last year of the 2nd millennium)
for rounding all years of the third millenium.
I also fixed the code so that all decades last 10 years and decade 199
means the 1990's.
I have added some tests that are relevant to deal with tricky cases. The
formula may be simplified, but all these cases must pass. Please keep
them.
Fabien Coelho
2004-08-20 05:45:14 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DECADE FROM DATE '0011-01-01 BC'); -- -1
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
-1
|
> After all that about numbering centuries and millenia correctly,
> why does CVS tip still give me
>
> regression=# select extract(century from now());
> date_part
> -----------
> 20
> (1 row)
> [ ... looks in code ... ]
>
> Apparently it's because you fixed only timestamp_part, and not
> timestamptz_part. I'm not too sure about what timestamp_trunc or
> timestamptz_trunc should do, but they may be wrong as well.
Sigh... as usual, what is not tested does not work:-(
> Could we have a more complete patch?
Please find a submission attached. I hope it really fixes all decade,
century and millenium issues for extract and *_trunc functions on
interval
and other timestamp types. If someone could check that the results
are reasonnable, it would be great.
I indeed overlooked the fact that there were two functions. The patch
fixes the code so that both variants agree.
I added comments to interval extractions, because it relies on the C
division to have a negative remainder: -7/10 = 0 and remains -7.
As for *_trunc functions, I have chosen to put the first year of the
century or millennium: -100, 1, 101... 1001 2001 etc. Indeed, I don't
think it would make sense to put 2000 (last year of the 2nd millennium)
for rounding all years of the third millenium.
I also fixed the code so that all decades last 10 years and decade 199
means the 1990's.
I have added some tests that are relevant to deal with tricky cases. The
formula may be simplified, but all these cases must pass. Please keep
them.
Fabien Coelho
2004-08-20 05:45:14 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DECADE FROM DATE '0012-12-31 BC'); -- -2
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
-2
|
> After all that about numbering centuries and millenia correctly,
> why does CVS tip still give me
>
> regression=# select extract(century from now());
> date_part
> -----------
> 20
> (1 row)
> [ ... looks in code ... ]
>
> Apparently it's because you fixed only timestamp_part, and not
> timestamptz_part. I'm not too sure about what timestamp_trunc or
> timestamptz_trunc should do, but they may be wrong as well.
Sigh... as usual, what is not tested does not work:-(
> Could we have a more complete patch?
Please find a submission attached. I hope it really fixes all decade,
century and millenium issues for extract and *_trunc functions on
interval
and other timestamp types. If someone could check that the results
are reasonnable, it would be great.
I indeed overlooked the fact that there were two functions. The patch
fixes the code so that both variants agree.
I added comments to interval extractions, because it relies on the C
division to have a negative remainder: -7/10 = 0 and remains -7.
As for *_trunc functions, I have chosen to put the first year of the
century or millennium: -100, 1, 101... 1001 2001 etc. Indeed, I don't
think it would make sense to put 2000 (last year of the 2nd millennium)
for rounding all years of the third millenium.
I also fixed the code so that all decades last 10 years and decade 199
means the 1990's.
I have added some tests that are relevant to deal with tricky cases. The
formula may be simplified, but all these cases must pass. Please keep
them.
Fabien Coelho
2004-08-20 05:45:14 +02:00
|
|
|
(1 row)
|
|
|
|
|
2020-09-10 14:52:36 +02:00
|
|
|
--
|
|
|
|
-- all possible fields
|
|
|
|
--
|
|
|
|
SELECT EXTRACT(MICROSECONDS FROM DATE '2020-08-11');
|
2022-01-03 20:05:03 +01:00
|
|
|
ERROR: unit "microseconds" not supported for type date
|
2020-09-10 14:52:36 +02:00
|
|
|
SELECT EXTRACT(MILLISECONDS FROM DATE '2020-08-11');
|
2022-01-03 20:05:03 +01:00
|
|
|
ERROR: unit "milliseconds" not supported for type date
|
2020-09-10 14:52:36 +02:00
|
|
|
SELECT EXTRACT(SECOND FROM DATE '2020-08-11');
|
2022-01-03 20:05:03 +01:00
|
|
|
ERROR: unit "second" not supported for type date
|
2020-09-10 14:52:36 +02:00
|
|
|
SELECT EXTRACT(MINUTE FROM DATE '2020-08-11');
|
2022-01-03 20:05:03 +01:00
|
|
|
ERROR: unit "minute" not supported for type date
|
2020-09-10 14:52:36 +02:00
|
|
|
SELECT EXTRACT(HOUR FROM DATE '2020-08-11');
|
2022-01-03 20:05:03 +01:00
|
|
|
ERROR: unit "hour" not supported for type date
|
2020-09-10 14:52:36 +02:00
|
|
|
SELECT EXTRACT(DAY FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
11
|
2020-09-10 14:52:36 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(MONTH FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
8
|
2020-09-10 14:52:36 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(YEAR FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
2020
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(YEAR FROM DATE '2020-08-11 BC');
|
|
|
|
extract
|
|
|
|
---------
|
|
|
|
-2020
|
2020-09-10 14:52:36 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DECADE FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
202
|
2020-09-10 14:52:36 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(CENTURY FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
21
|
2020-09-10 14:52:36 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(MILLENNIUM FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
3
|
2020-09-10 14:52:36 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(ISOYEAR FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
2020
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(ISOYEAR FROM DATE '2020-08-11 BC');
|
|
|
|
extract
|
|
|
|
---------
|
|
|
|
-2020
|
2020-09-10 14:52:36 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(QUARTER FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
3
|
2020-09-10 14:52:36 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(WEEK FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
33
|
2020-09-10 14:52:36 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DOW FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DOW FROM DATE '2020-08-16');
|
|
|
|
extract
|
|
|
|
---------
|
|
|
|
0
|
2020-09-10 14:52:36 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(ISODOW FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(ISODOW FROM DATE '2020-08-16');
|
|
|
|
extract
|
|
|
|
---------
|
|
|
|
7
|
2020-09-10 14:52:36 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DOY FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
224
|
2020-09-10 14:52:36 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(TIMEZONE FROM DATE '2020-08-11');
|
2022-01-03 20:05:03 +01:00
|
|
|
ERROR: unit "timezone" not supported for type date
|
2020-09-10 14:52:36 +02:00
|
|
|
SELECT EXTRACT(TIMEZONE_M FROM DATE '2020-08-11');
|
2022-01-03 20:05:03 +01:00
|
|
|
ERROR: unit "timezone_m" not supported for type date
|
2020-09-10 14:52:36 +02:00
|
|
|
SELECT EXTRACT(TIMEZONE_H FROM DATE '2020-08-11');
|
2022-01-03 20:05:03 +01:00
|
|
|
ERROR: unit "timezone_h" not supported for type date
|
2020-09-10 14:52:36 +02:00
|
|
|
SELECT EXTRACT(EPOCH FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
2020-09-10 14:52:36 +02:00
|
|
|
------------
|
|
|
|
1597104000
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(JULIAN FROM DATE '2020-08-11');
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
2459073
|
2020-09-10 14:52:36 +02:00
|
|
|
(1 row)
|
|
|
|
|
> After all that about numbering centuries and millenia correctly,
> why does CVS tip still give me
>
> regression=# select extract(century from now());
> date_part
> -----------
> 20
> (1 row)
> [ ... looks in code ... ]
>
> Apparently it's because you fixed only timestamp_part, and not
> timestamptz_part. I'm not too sure about what timestamp_trunc or
> timestamptz_trunc should do, but they may be wrong as well.
Sigh... as usual, what is not tested does not work:-(
> Could we have a more complete patch?
Please find a submission attached. I hope it really fixes all decade,
century and millenium issues for extract and *_trunc functions on
interval
and other timestamp types. If someone could check that the results
are reasonnable, it would be great.
I indeed overlooked the fact that there were two functions. The patch
fixes the code so that both variants agree.
I added comments to interval extractions, because it relies on the C
division to have a negative remainder: -7/10 = 0 and remains -7.
As for *_trunc functions, I have chosen to put the first year of the
century or millennium: -100, 1, 101... 1001 2001 etc. Indeed, I don't
think it would make sense to put 2000 (last year of the 2nd millennium)
for rounding all years of the third millenium.
I also fixed the code so that all decades last 10 years and decade 199
means the 1990's.
I have added some tests that are relevant to deal with tricky cases. The
formula may be simplified, but all these cases must pass. Please keep
them.
Fabien Coelho
2004-08-20 05:45:14 +02:00
|
|
|
--
|
|
|
|
-- test trunc function!
|
|
|
|
--
|
|
|
|
SELECT DATE_TRUNC('MILLENNIUM', TIMESTAMP '1970-03-20 04:30:00.00000'); -- 1001
|
|
|
|
date_trunc
|
|
|
|
--------------------------
|
|
|
|
Thu Jan 01 00:00:00 1001
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT DATE_TRUNC('MILLENNIUM', DATE '1970-03-20'); -- 1001-01-01
|
|
|
|
date_trunc
|
|
|
|
------------------------------
|
|
|
|
Thu Jan 01 00:00:00 1001 PST
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT DATE_TRUNC('CENTURY', TIMESTAMP '1970-03-20 04:30:00.00000'); -- 1901
|
|
|
|
date_trunc
|
|
|
|
--------------------------
|
|
|
|
Tue Jan 01 00:00:00 1901
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT DATE_TRUNC('CENTURY', DATE '1970-03-20'); -- 1901
|
|
|
|
date_trunc
|
|
|
|
------------------------------
|
|
|
|
Tue Jan 01 00:00:00 1901 PST
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT DATE_TRUNC('CENTURY', DATE '2004-08-10'); -- 2001-01-01
|
|
|
|
date_trunc
|
|
|
|
------------------------------
|
|
|
|
Mon Jan 01 00:00:00 2001 PST
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT DATE_TRUNC('CENTURY', DATE '0002-02-04'); -- 0001-01-01
|
|
|
|
date_trunc
|
|
|
|
------------------------------
|
|
|
|
Mon Jan 01 00:00:00 0001 PST
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT DATE_TRUNC('CENTURY', DATE '0055-08-10 BC'); -- 0100-01-01 BC
|
|
|
|
date_trunc
|
|
|
|
---------------------------------
|
|
|
|
Tue Jan 01 00:00:00 0100 PST BC
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT DATE_TRUNC('DECADE', DATE '1993-12-25'); -- 1990-01-01
|
|
|
|
date_trunc
|
|
|
|
------------------------------
|
|
|
|
Mon Jan 01 00:00:00 1990 PST
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT DATE_TRUNC('DECADE', DATE '0004-12-25'); -- 0001-01-01 BC
|
|
|
|
date_trunc
|
|
|
|
---------------------------------
|
|
|
|
Sat Jan 01 00:00:00 0001 PST BC
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT DATE_TRUNC('DECADE', DATE '0002-12-31 BC'); -- 0011-01-01 BC
|
|
|
|
date_trunc
|
|
|
|
---------------------------------
|
|
|
|
Mon Jan 01 00:00:00 0011 PST BC
|
|
|
|
(1 row)
|
|
|
|
|
2008-10-14 19:12:33 +02:00
|
|
|
--
|
|
|
|
-- test infinity
|
|
|
|
--
|
|
|
|
select 'infinity'::date, '-infinity'::date;
|
|
|
|
date | date
|
|
|
|
----------+-----------
|
|
|
|
infinity | -infinity
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select 'infinity'::date > 'today'::date as t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select '-infinity'::date < 'today'::date as t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
select isfinite('infinity'::date), isfinite('-infinity'::date), isfinite('today'::date);
|
|
|
|
isfinite | isfinite | isfinite
|
|
|
|
----------+----------+----------
|
|
|
|
f | f | t
|
|
|
|
(1 row)
|
|
|
|
|
2016-01-22 04:26:20 +01:00
|
|
|
--
|
2021-03-29 17:53:30 +02:00
|
|
|
-- oscillating fields from non-finite date:
|
2016-01-22 04:26:20 +01:00
|
|
|
--
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
SELECT EXTRACT(DAY FROM DATE 'infinity'); -- NULL
|
|
|
|
extract
|
|
|
|
---------
|
|
|
|
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
SELECT EXTRACT(DAY FROM DATE '-infinity'); -- NULL
|
|
|
|
extract
|
|
|
|
---------
|
|
|
|
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
-- all supported fields
|
2016-01-22 04:26:20 +01:00
|
|
|
SELECT EXTRACT(DAY FROM DATE 'infinity'); -- NULL
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(MONTH FROM DATE 'infinity'); -- NULL
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(QUARTER FROM DATE 'infinity'); -- NULL
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(WEEK FROM DATE 'infinity'); -- NULL
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DOW FROM DATE 'infinity'); -- NULL
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(ISODOW FROM DATE 'infinity'); -- NULL
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DOY FROM DATE 'infinity'); -- NULL
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
---------
|
|
|
|
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
--
|
2021-03-29 17:53:30 +02:00
|
|
|
-- monotonic fields from non-finite date:
|
2016-01-22 04:26:20 +01:00
|
|
|
--
|
|
|
|
SELECT EXTRACT(EPOCH FROM DATE 'infinity'); -- Infinity
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
----------
|
|
|
|
Infinity
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(EPOCH FROM DATE '-infinity'); -- -Infinity
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
2016-01-22 04:26:20 +01:00
|
|
|
-----------
|
|
|
|
-Infinity
|
|
|
|
(1 row)
|
|
|
|
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
-- all supported fields
|
2016-01-22 04:26:20 +01:00
|
|
|
SELECT EXTRACT(YEAR FROM DATE 'infinity'); -- Infinity
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
----------
|
|
|
|
Infinity
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DECADE FROM DATE 'infinity'); -- Infinity
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
----------
|
|
|
|
Infinity
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(CENTURY FROM DATE 'infinity'); -- Infinity
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
----------
|
|
|
|
Infinity
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(MILLENNIUM FROM DATE 'infinity'); -- Infinity
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
----------
|
|
|
|
Infinity
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(JULIAN FROM DATE 'infinity'); -- Infinity
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
----------
|
|
|
|
Infinity
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(ISOYEAR FROM DATE 'infinity'); -- Infinity
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
----------
|
|
|
|
Infinity
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(EPOCH FROM DATE 'infinity'); -- Infinity
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
extract
|
|
|
|
----------
|
|
|
|
Infinity
|
2016-01-22 04:26:20 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
--
|
|
|
|
-- wrong fields from non-finite date:
|
|
|
|
--
|
Change return type of EXTRACT to numeric
The previous implementation of EXTRACT mapped internally to
date_part(), which returned type double precision (since it was
implemented long before the numeric type existed). This can lead to
imprecise output in some cases, so returning numeric would be
preferrable. Changing the return type of an existing function is a
bit risky, so instead we do the following: We implement a new set of
functions, which are now called "extract", in parallel to the existing
date_part functions. They work the same way internally but use
numeric instead of float8. The EXTRACT construct is now mapped by the
parser to these new extract functions. That way, dumps of views
etc. from old versions (which would use date_part) continue to work
unchanged, but new uses will map to the new extract functions.
Additionally, the reverse compilation of EXTRACT now reproduces the
original syntax, using the new mechanism introduced in
40c24bfef92530bd846e111c1742c2a54441c62c.
The following minor changes of behavior result from the new
implementation:
- The column name from an isolated EXTRACT call is now "extract"
instead of "date_part".
- Extract from date now rejects inappropriate field names such as
HOUR. It was previously mapped internally to extract from
timestamp, so it would silently accept everything appropriate for
timestamp.
- Return values when extracting fields with possibly fractional
values, such as second and epoch, now have the full scale that the
value has internally (so, for example, '1.000000' instead of just
'1').
Reported-by: Petr Fedorov <petr.fedorov@phystech.edu>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/42b73d2d-da12-ba9f-570a-420e0cce19d9@phystech.edu
2021-04-06 07:17:13 +02:00
|
|
|
SELECT EXTRACT(MICROSEC FROM DATE 'infinity'); -- error
|
2022-01-03 20:05:03 +01:00
|
|
|
ERROR: unit "microsec" not recognized for type date
|
2013-11-17 21:06:50 +01:00
|
|
|
-- test constructors
|
|
|
|
select make_date(2013, 7, 15);
|
|
|
|
make_date
|
|
|
|
------------
|
|
|
|
07-15-2013
|
|
|
|
(1 row)
|
|
|
|
|
2017-01-19 13:45:38 +01:00
|
|
|
select make_date(-44, 3, 15);
|
|
|
|
make_date
|
|
|
|
---------------
|
|
|
|
03-15-0044 BC
|
|
|
|
(1 row)
|
|
|
|
|
2013-11-17 21:06:50 +01:00
|
|
|
select make_time(8, 20, 0.0);
|
|
|
|
make_time
|
|
|
|
-----------
|
|
|
|
08:20:00
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- should fail
|
2020-09-29 19:48:06 +02:00
|
|
|
select make_date(0, 7, 15);
|
|
|
|
ERROR: date field value out of range: 0-07-15
|
2013-11-17 21:06:50 +01:00
|
|
|
select make_date(2013, 2, 30);
|
|
|
|
ERROR: date field value out of range: 2013-02-30
|
|
|
|
select make_date(2013, 13, 1);
|
|
|
|
ERROR: date field value out of range: 2013-13-01
|
|
|
|
select make_date(2013, 11, -1);
|
|
|
|
ERROR: date field value out of range: 2013-11--1
|
|
|
|
select make_time(10, 55, 100.1);
|
|
|
|
ERROR: time field value out of range: 10:55:100.1
|
|
|
|
select make_time(24, 0, 2.1);
|
|
|
|
ERROR: time field value out of range: 24:00:2.1
|