Prevent internal overflows in date-vs-timestamp and related comparisons.
The date-vs-timestamp, date-vs-timestamptz, and timestamp-vs-timestamptz
comparators all worked by promoting the first type to the second and
then doing a simple same-type comparison. This works fine, except
when the conversion result is out of range, in which case we throw an
entirely avoidable error. The sources of such failures are
(a) type date can represent dates much farther in the future than
the timestamp types can;
(b) timezone rotation might cause a just-in-range timestamp value to
become a just-out-of-range timestamptz value.
Up to now we just ignored these corner-case issues, but now we have
an actual user complaint (bug #16657 from Huss EL-Sheikh), so let's
do something about it.
It turns out that commit 52ad1e659 already built all the necessary
infrastructure to support error-free comparisons, but neglected to
actually use it in the main-line code paths. Fix that, do a little
bit of code style review, and remove the now-duplicate logic in
jsonpath_exec.c.
Back-patch to v13 where 52ad1e659 came in. We could take this back
further by back-patching said infrastructure, but given the small
number of complaints so far, I don't feel a great need to.
Discussion: https://postgr.es/m/16657-cde2f876d8cc7971@postgresql.org
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/3db322eaab9688d57643b4d2a5f52b7f350ef46f
Modified Files
--------------
src/backend/utils/adt/date.c | 222 ++++++++++++++-------------------
src/backend/utils/adt/jsonpath_exec.c | 71 ++---------
src/backend/utils/adt/timestamp.c | 115 ++++++++---------
src/include/utils/date.h | 3 +
src/include/utils/timestamp.h | 2 +
src/test/regress/expected/horology.out | 72 +++++++++++
src/test/regress/sql/horology.sql | 27 ++++
7 files changed, 260 insertions(+), 252 deletions(-)
