mirror of
https://git.postgresql.org/git/postgresql.git
synced 2026-02-15 02:46:59 +08:00
6490376e56
It's intentional that we don't allow values greater than 24 hours, while we do allow "24:00:00" as well as "23:59:60" as inputs. However, the range check was miscoded in such a way that it would accept "23:59:60.nnn" with a nonzero fraction. For time or timetz, the stored result would then be greater than "24:00:00" which would fail dump/reload, not to mention possibly confusing other operations. Fix by explicitly calculating the result and making sure it does not exceed 24 hours. (This calculation is redundant with what will happen later in tm2time or tm2timetz. Maybe someday somebody will find that annoying enough to justify refactoring to avoid the duplication; but that seems too invasive for a back-patched bug fix, and the cost is probably unmeasurable anyway.) Note that this change also rejects such input as the time portion of a timestamp(tz) value. Back-patch to v10. The bug is far older, but to change this pre-v10 we'd need to ensure that the logic behaves sanely with float timestamps, which is possibly nontrivial due to roundoff considerations. Doesn't really seem worth troubling with. Per report from Christoph Berg. Discussion: https://postgr.es/m/20200520125807.GB296739@msg.df7cb.de
53 lines
1.6 KiB
SQL
53 lines
1.6 KiB
SQL
--
|
|
-- TIME
|
|
--
|
|
|
|
CREATE TABLE TIME_TBL (f1 time(2));
|
|
|
|
INSERT INTO TIME_TBL VALUES ('00:00');
|
|
INSERT INTO TIME_TBL VALUES ('01:00');
|
|
-- as of 7.4, timezone spec should be accepted and ignored
|
|
INSERT INTO TIME_TBL VALUES ('02:03 PST');
|
|
INSERT INTO TIME_TBL VALUES ('11:59 EDT');
|
|
INSERT INTO TIME_TBL VALUES ('12:00');
|
|
INSERT INTO TIME_TBL VALUES ('12:01');
|
|
INSERT INTO TIME_TBL VALUES ('23:59');
|
|
INSERT INTO TIME_TBL VALUES ('11:59:59.99 PM');
|
|
|
|
INSERT INTO TIME_TBL VALUES ('2003-03-07 15:36:39 America/New_York');
|
|
INSERT INTO TIME_TBL VALUES ('2003-07-07 15:36:39 America/New_York');
|
|
-- this should fail (the timezone offset is not known)
|
|
INSERT INTO TIME_TBL VALUES ('15:36:39 America/New_York');
|
|
|
|
|
|
SELECT f1 AS "Time" FROM TIME_TBL;
|
|
|
|
SELECT f1 AS "Three" FROM TIME_TBL WHERE f1 < '05:06:07';
|
|
|
|
SELECT f1 AS "Five" FROM TIME_TBL WHERE f1 > '05:06:07';
|
|
|
|
SELECT f1 AS "None" FROM TIME_TBL WHERE f1 < '00:00';
|
|
|
|
SELECT f1 AS "Eight" FROM TIME_TBL WHERE f1 >= '00:00';
|
|
|
|
-- Check edge cases
|
|
SELECT '23:59:59.999999'::time;
|
|
SELECT '23:59:59.9999999'::time; -- rounds up
|
|
SELECT '23:59:60'::time; -- rounds up
|
|
SELECT '24:00:00'::time; -- allowed
|
|
SELECT '24:00:00.01'::time; -- not allowed
|
|
SELECT '23:59:60.01'::time; -- not allowed
|
|
SELECT '24:01:00'::time; -- not allowed
|
|
SELECT '25:00:00'::time; -- not allowed
|
|
|
|
--
|
|
-- 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 '00:01' AS "Illegal" FROM TIME_TBL;
|