2001-09-28 10:00:11 +02:00
|
|
|
--
|
|
|
|
-- TIMETZ
|
|
|
|
--
|
2001-10-03 07:29:27 +02:00
|
|
|
CREATE TABLE TIMETZ_TBL (f1 time(2) with time zone);
|
2001-09-28 10:00:11 +02:00
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('00:01 PDT');
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('01:00 PDT');
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('02:03 PDT');
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('07:07 PST');
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('08:08 EDT');
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('11:59 PDT');
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('12:00 PDT');
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('12:01 PDT');
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('23:59 PDT');
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('11:59:59.99 PM PDT');
|
2006-07-06 03:46:38 +02:00
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('2003-03-07 15:36:39 America/New_York');
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('2003-07-07 15:36:39 America/New_York');
|
|
|
|
-- this should fail (the timezone offset is not known)
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('15:36:39 America/New_York');
|
|
|
|
ERROR: invalid input syntax for type time with time zone: "15:36:39 America/New_York"
|
2008-09-01 22:42:46 +02:00
|
|
|
LINE 1: INSERT INTO TIMETZ_TBL VALUES ('15:36:39 America/New_York');
|
|
|
|
^
|
2019-08-07 11:16:31 +02:00
|
|
|
-- this should fail (timezone not specified without a date)
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('15:36:39 m2');
|
|
|
|
ERROR: invalid input syntax for type time with time zone: "15:36:39 m2"
|
|
|
|
LINE 1: INSERT INTO TIMETZ_TBL VALUES ('15:36:39 m2');
|
|
|
|
^
|
|
|
|
-- this should fail (dynamic timezone abbreviation without a date)
|
|
|
|
INSERT INTO TIMETZ_TBL VALUES ('15:36:39 MSK m2');
|
|
|
|
ERROR: invalid input syntax for type time with time zone: "15:36:39 MSK m2"
|
|
|
|
LINE 1: INSERT INTO TIMETZ_TBL VALUES ('15:36:39 MSK m2');
|
|
|
|
^
|
2001-09-28 10:00:11 +02:00
|
|
|
SELECT f1 AS "Time TZ" FROM TIMETZ_TBL;
|
2001-10-03 07:29:27 +02:00
|
|
|
Time TZ
|
|
|
|
----------------
|
2001-09-28 10:00:11 +02:00
|
|
|
00:01:00-07
|
|
|
|
01:00:00-07
|
|
|
|
02:03:00-07
|
|
|
|
07:07:00-08
|
|
|
|
08:08:00-04
|
|
|
|
11:59:00-07
|
|
|
|
12:00:00-07
|
|
|
|
12:01:00-07
|
|
|
|
23:59:00-07
|
2001-10-03 07:29:27 +02:00
|
|
|
23:59:59.99-07
|
2006-07-06 03:46:38 +02:00
|
|
|
15:36:39-05
|
|
|
|
15:36:39-04
|
|
|
|
(12 rows)
|
2001-09-28 10:00:11 +02:00
|
|
|
|
2001-10-31 15:44:23 +01:00
|
|
|
SELECT f1 AS "Three" FROM TIMETZ_TBL WHERE f1 < '05:06:07-07';
|
2001-09-28 10:00:11 +02:00
|
|
|
Three
|
|
|
|
-------------
|
|
|
|
00:01:00-07
|
|
|
|
01:00:00-07
|
|
|
|
02:03:00-07
|
|
|
|
(3 rows)
|
|
|
|
|
2001-10-31 15:44:23 +01:00
|
|
|
SELECT f1 AS "Seven" FROM TIMETZ_TBL WHERE f1 > '05:06:07-07';
|
2001-10-03 07:29:27 +02:00
|
|
|
Seven
|
|
|
|
----------------
|
2001-09-28 10:00:11 +02:00
|
|
|
07:07:00-08
|
|
|
|
08:08:00-04
|
|
|
|
11:59:00-07
|
|
|
|
12:00:00-07
|
|
|
|
12:01:00-07
|
|
|
|
23:59:00-07
|
2001-10-03 07:29:27 +02:00
|
|
|
23:59:59.99-07
|
2006-07-06 03:46:38 +02:00
|
|
|
15:36:39-05
|
|
|
|
15:36:39-04
|
|
|
|
(9 rows)
|
2001-09-28 10:00:11 +02:00
|
|
|
|
2001-10-31 15:44:23 +01:00
|
|
|
SELECT f1 AS "None" FROM TIMETZ_TBL WHERE f1 < '00:00-07';
|
2001-09-28 10:00:11 +02:00
|
|
|
None
|
|
|
|
------
|
|
|
|
(0 rows)
|
|
|
|
|
2001-10-31 15:44:23 +01:00
|
|
|
SELECT f1 AS "Ten" FROM TIMETZ_TBL WHERE f1 >= '00:00-07';
|
2001-10-03 07:29:27 +02:00
|
|
|
Ten
|
|
|
|
----------------
|
2001-09-28 10:00:11 +02:00
|
|
|
00:01:00-07
|
|
|
|
01:00:00-07
|
|
|
|
02:03:00-07
|
|
|
|
07:07:00-08
|
|
|
|
08:08:00-04
|
|
|
|
11:59:00-07
|
|
|
|
12:00:00-07
|
|
|
|
12:01:00-07
|
|
|
|
23:59:00-07
|
2001-10-03 07:29:27 +02:00
|
|
|
23:59:59.99-07
|
2006-07-06 03:46:38 +02:00
|
|
|
15:36:39-05
|
|
|
|
15:36:39-04
|
|
|
|
(12 rows)
|
2001-09-28 10:00:11 +02:00
|
|
|
|
2020-06-04 22:42:08 +02:00
|
|
|
-- Check edge cases
|
2020-10-29 20:28:14 +01:00
|
|
|
SELECT '23:59:59.999999 PDT'::timetz;
|
2020-06-04 22:42:08 +02:00
|
|
|
timetz
|
|
|
|
--------------------
|
|
|
|
23:59:59.999999-07
|
|
|
|
(1 row)
|
|
|
|
|
2020-10-29 20:28:14 +01:00
|
|
|
SELECT '23:59:59.9999999 PDT'::timetz; -- rounds up
|
2020-06-04 22:42:08 +02:00
|
|
|
timetz
|
|
|
|
-------------
|
|
|
|
24:00:00-07
|
|
|
|
(1 row)
|
|
|
|
|
2020-10-29 20:28:14 +01:00
|
|
|
SELECT '23:59:60 PDT'::timetz; -- rounds up
|
2020-06-04 22:42:08 +02:00
|
|
|
timetz
|
|
|
|
-------------
|
|
|
|
24:00:00-07
|
|
|
|
(1 row)
|
|
|
|
|
2020-10-29 20:28:14 +01:00
|
|
|
SELECT '24:00:00 PDT'::timetz; -- allowed
|
2020-06-04 22:42:08 +02:00
|
|
|
timetz
|
|
|
|
-------------
|
|
|
|
24:00:00-07
|
|
|
|
(1 row)
|
|
|
|
|
2020-10-29 20:28:14 +01:00
|
|
|
SELECT '24:00:00.01 PDT'::timetz; -- not allowed
|
|
|
|
ERROR: date/time field value out of range: "24:00:00.01 PDT"
|
|
|
|
LINE 1: SELECT '24:00:00.01 PDT'::timetz;
|
2020-06-04 22:42:08 +02:00
|
|
|
^
|
2020-10-29 20:28:14 +01:00
|
|
|
SELECT '23:59:60.01 PDT'::timetz; -- not allowed
|
|
|
|
ERROR: date/time field value out of range: "23:59:60.01 PDT"
|
|
|
|
LINE 1: SELECT '23:59:60.01 PDT'::timetz;
|
2020-06-04 22:42:08 +02:00
|
|
|
^
|
2020-10-29 20:28:14 +01:00
|
|
|
SELECT '24:01:00 PDT'::timetz; -- not allowed
|
|
|
|
ERROR: date/time field value out of range: "24:01:00 PDT"
|
|
|
|
LINE 1: SELECT '24:01:00 PDT'::timetz;
|
2020-06-04 22:42:08 +02:00
|
|
|
^
|
2020-10-29 20:28:14 +01:00
|
|
|
SELECT '25:00:00 PDT'::timetz; -- not allowed
|
|
|
|
ERROR: date/time field value out of range: "25:00:00 PDT"
|
|
|
|
LINE 1: SELECT '25:00:00 PDT'::timetz;
|
2020-06-04 22:42:08 +02:00
|
|
|
^
|
2022-12-09 22:07:49 +01:00
|
|
|
-- Test non-error-throwing API
|
|
|
|
SELECT pg_input_is_valid('12:00:00 PDT', 'timetz');
|
|
|
|
pg_input_is_valid
|
|
|
|
-------------------
|
|
|
|
t
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT pg_input_is_valid('25:00:00 PDT', 'timetz');
|
|
|
|
pg_input_is_valid
|
|
|
|
-------------------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT pg_input_is_valid('15:36:39 America/New_York', 'timetz');
|
|
|
|
pg_input_is_valid
|
|
|
|
-------------------
|
|
|
|
f
|
|
|
|
(1 row)
|
|
|
|
|
2023-02-28 00:04:13 +01:00
|
|
|
SELECT * FROM pg_input_error_info('25:00:00 PDT', 'timetz');
|
|
|
|
message | detail | hint | sql_error_code
|
|
|
|
----------------------------------------------------+--------+------+----------------
|
|
|
|
date/time field value out of range: "25:00:00 PDT" | | | 22008
|
2022-12-09 22:07:49 +01:00
|
|
|
(1 row)
|
|
|
|
|
2023-02-28 00:04:13 +01:00
|
|
|
SELECT * FROM pg_input_error_info('15:36:39 America/New_York', 'timetz');
|
|
|
|
message | detail | hint | sql_error_code
|
|
|
|
--------------------------------------------------------------------------------+--------+------+----------------
|
|
|
|
invalid input syntax for type time with time zone: "15:36:39 America/New_York" | | | 22007
|
2022-12-09 22:07:49 +01:00
|
|
|
(1 row)
|
|
|
|
|
2001-09-28 10:00:11 +02:00
|
|
|
--
|
|
|
|
-- TIME simple math
|
|
|
|
--
|
|
|
|
-- We now make a distinction between time and intervals,
|
|
|
|
-- and adding two times together makes no sense at all.
|
|
|
|
-- Leave in one query to show that it is rejected,
|
|
|
|
-- and do the rest of the testing in horology.sql
|
|
|
|
-- where we do mixed-type arithmetic. - thomas 2000-12-02
|
|
|
|
SELECT f1 + time with time zone '00:01' AS "Illegal" FROM TIMETZ_TBL;
|
2003-07-04 04:51:34 +02:00
|
|
|
ERROR: operator does not exist: time with time zone + time with time zone
|
2006-03-14 23:48:25 +01:00
|
|
|
LINE 1: SELECT f1 + time with time zone '00:01' AS "Illegal" FROM TI...
|
|
|
|
^
|
2017-08-23 19:56:59 +02:00
|
|
|
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
|
2020-06-14 07:48:15 +02:00
|
|
|
--
|
|
|
|
-- test EXTRACT
|
|
|
|
--
|
|
|
|
SELECT EXTRACT(MICROSECOND FROM TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04');
|
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
|
|
|
|
----------
|
|
|
|
25575401
|
2020-06-14 07:48:15 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(MILLISECOND FROM TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04');
|
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-06-14 07:48:15 +02:00
|
|
|
-----------
|
|
|
|
25575.401
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(SECOND FROM TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04');
|
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-06-14 07:48:15 +02:00
|
|
|
-----------
|
|
|
|
25.575401
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(MINUTE FROM TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04');
|
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
|
|
|
|
---------
|
|
|
|
30
|
2020-06-14 07:48:15 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(HOUR FROM TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04');
|
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
|
|
|
|
---------
|
|
|
|
13
|
2020-06-14 07:48:15 +02:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(DAY FROM TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04'); -- error
|
2022-01-03 20:05:03 +01:00
|
|
|
ERROR: unit "day" not supported for type time with time zone
|
2020-06-14 07:48:15 +02:00
|
|
|
SELECT EXTRACT(FORTNIGHT FROM TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04'); -- error
|
2022-01-03 20:05:03 +01:00
|
|
|
ERROR: unit "fortnight" not recognized for type time with time zone
|
2021-04-01 09:52:03 +02:00
|
|
|
SELECT EXTRACT(TIMEZONE FROM TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04:30');
|
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
|
|
|
|
---------
|
|
|
|
-16200
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(TIMEZONE_HOUR FROM TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04:30');
|
|
|
|
extract
|
|
|
|
---------
|
|
|
|
-4
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(TIMEZONE_MINUTE FROM TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04:30');
|
|
|
|
extract
|
|
|
|
---------
|
|
|
|
-30
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
SELECT EXTRACT(EPOCH FROM TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04');
|
|
|
|
extract
|
|
|
|
--------------
|
|
|
|
63025.575401
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- date_part implementation is mostly the same as extract, so only
|
|
|
|
-- test a few cases for additional coverage.
|
|
|
|
SELECT date_part('microsecond', TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04');
|
2020-06-14 07:48:15 +02:00
|
|
|
date_part
|
|
|
|
-----------
|
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
|
|
|
25575401
|
2020-06-14 07:48:15 +02: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 date_part('millisecond', TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04');
|
2020-06-14 07:48:15 +02:00
|
|
|
date_part
|
|
|
|
-----------
|
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
|
|
|
25575.401
|
2020-06-14 07:48:15 +02: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 date_part('second', TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04');
|
2020-06-14 07:48:15 +02:00
|
|
|
date_part
|
|
|
|
-----------
|
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
|
|
|
25.575401
|
2020-06-14 07:48:15 +02: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 date_part('epoch', TIME WITH TIME ZONE '2020-05-26 13:30:25.575401-04');
|
2020-06-14 07:48:15 +02:00
|
|
|
date_part
|
|
|
|
--------------
|
|
|
|
63025.575401
|
|
|
|
(1 row)
|
|
|
|
|
2023-10-13 06:01:37 +02:00
|
|
|
--
|
2023-10-16 21:45:01 +02:00
|
|
|
-- Test timetz_zone, timetz_izone, AT LOCAL
|
2023-10-13 06:01:37 +02:00
|
|
|
--
|
|
|
|
BEGIN;
|
|
|
|
SET LOCAL TimeZone TO 'UTC';
|
|
|
|
CREATE VIEW timetz_local_view AS
|
|
|
|
SELECT f1 AS dat,
|
|
|
|
timezone(f1) AS dat_func,
|
|
|
|
f1 AT LOCAL AS dat_at_local,
|
2023-10-16 21:45:01 +02:00
|
|
|
f1 AT TIME ZONE current_setting('TimeZone') AS dat_at_tz,
|
|
|
|
f1 AT TIME ZONE INTERVAL '00:00' AS dat_at_int
|
2023-10-13 06:01:37 +02:00
|
|
|
FROM TIMETZ_TBL
|
|
|
|
ORDER BY f1;
|
|
|
|
SELECT pg_get_viewdef('timetz_local_view', true);
|
2023-10-16 21:45:01 +02:00
|
|
|
pg_get_viewdef
|
|
|
|
-----------------------------------------------------------------------
|
|
|
|
SELECT f1 AS dat, +
|
|
|
|
timezone(f1) AS dat_func, +
|
|
|
|
(f1 AT LOCAL) AS dat_at_local, +
|
|
|
|
(f1 AT TIME ZONE current_setting('TimeZone'::text)) AS dat_at_tz,+
|
|
|
|
(f1 AT TIME ZONE '@ 0'::interval) AS dat_at_int +
|
|
|
|
FROM timetz_tbl +
|
2023-10-13 06:01:37 +02:00
|
|
|
ORDER BY f1;
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
TABLE timetz_local_view;
|
2023-10-16 21:45:01 +02:00
|
|
|
dat | dat_func | dat_at_local | dat_at_tz | dat_at_int
|
|
|
|
----------------+----------------+----------------+----------------+----------------
|
|
|
|
00:01:00-07 | 07:01:00+00 | 07:01:00+00 | 07:01:00+00 | 07:01:00+00
|
|
|
|
01:00:00-07 | 08:00:00+00 | 08:00:00+00 | 08:00:00+00 | 08:00:00+00
|
|
|
|
02:03:00-07 | 09:03:00+00 | 09:03:00+00 | 09:03:00+00 | 09:03:00+00
|
|
|
|
08:08:00-04 | 12:08:00+00 | 12:08:00+00 | 12:08:00+00 | 12:08:00+00
|
|
|
|
07:07:00-08 | 15:07:00+00 | 15:07:00+00 | 15:07:00+00 | 15:07:00+00
|
|
|
|
11:59:00-07 | 18:59:00+00 | 18:59:00+00 | 18:59:00+00 | 18:59:00+00
|
|
|
|
12:00:00-07 | 19:00:00+00 | 19:00:00+00 | 19:00:00+00 | 19:00:00+00
|
|
|
|
12:01:00-07 | 19:01:00+00 | 19:01:00+00 | 19:01:00+00 | 19:01:00+00
|
|
|
|
15:36:39-04 | 19:36:39+00 | 19:36:39+00 | 19:36:39+00 | 19:36:39+00
|
|
|
|
15:36:39-05 | 20:36:39+00 | 20:36:39+00 | 20:36:39+00 | 20:36:39+00
|
|
|
|
23:59:00-07 | 06:59:00+00 | 06:59:00+00 | 06:59:00+00 | 06:59:00+00
|
|
|
|
23:59:59.99-07 | 06:59:59.99+00 | 06:59:59.99+00 | 06:59:59.99+00 | 06:59:59.99+00
|
2023-10-13 06:01:37 +02:00
|
|
|
(12 rows)
|
|
|
|
|
2023-10-17 19:10:32 +02:00
|
|
|
SELECT f1 AS dat,
|
|
|
|
f1 AT TIME ZONE 'UTC+10' AS dat_at_tz,
|
|
|
|
f1 AT TIME ZONE INTERVAL '-10:00' AS dat_at_int
|
|
|
|
FROM TIMETZ_TBL
|
|
|
|
ORDER BY f1;
|
|
|
|
dat | dat_at_tz | dat_at_int
|
|
|
|
----------------+----------------+----------------
|
|
|
|
00:01:00-07 | 21:01:00-10 | 21:01:00-10
|
|
|
|
01:00:00-07 | 22:00:00-10 | 22:00:00-10
|
|
|
|
02:03:00-07 | 23:03:00-10 | 23:03:00-10
|
|
|
|
08:08:00-04 | 02:08:00-10 | 02:08:00-10
|
|
|
|
07:07:00-08 | 05:07:00-10 | 05:07:00-10
|
|
|
|
11:59:00-07 | 08:59:00-10 | 08:59:00-10
|
|
|
|
12:00:00-07 | 09:00:00-10 | 09:00:00-10
|
|
|
|
12:01:00-07 | 09:01:00-10 | 09:01:00-10
|
|
|
|
15:36:39-04 | 09:36:39-10 | 09:36:39-10
|
|
|
|
15:36:39-05 | 10:36:39-10 | 10:36:39-10
|
|
|
|
23:59:00-07 | 20:59:00-10 | 20:59:00-10
|
|
|
|
23:59:59.99-07 | 20:59:59.99-10 | 20:59:59.99-10
|
|
|
|
(12 rows)
|
|
|
|
|
2023-10-16 21:45:01 +02:00
|
|
|
ROLLBACK;
|