Be more careful about out-of-range dates and timestamps.
authorTom Lane <[email protected]>
Wed, 16 Mar 2016 23:09:04 +0000 (19:09 -0400)
committerTom Lane <[email protected]>
Wed, 16 Mar 2016 23:09:28 +0000 (19:09 -0400)
commita70e13a39eccf5fc944c66e0029004b6abcb3cae
treeffc2d894a16b329f5968e1ff1a6c4a89e5bca889
parentf2b74b01d4a18241bd7560e74d527f3ba42d4738
Be more careful about out-of-range dates and timestamps.

Tighten the semantics of boundary-case timestamptz so that we allow
timestamps >= '4714-11-24 00:00+00 BC' and < 'ENDYEAR-01-01 00:00+00 AD'
exactly, no more and no less, but it is allowed to enter timestamps
within that range using non-GMT timezone offsets (which could make the
nominal date 4714-11-23 BC or ENDYEAR-01-01 AD).  This eliminates
dump/reload failure conditions for timestamps near the endpoints.
To do this, separate checking of the inputs for date2j() from the
final range check, and allow the Julian date code to handle a range
slightly wider than the nominal range of the datatypes.

Also add a bunch of checks to detect out-of-range dates and timestamps
that formerly could be returned by operations such as date-plus-integer.
All C-level functions that return date, timestamp, or timestamptz should
now be proof against returning a value that doesn't pass IS_VALID_DATE()
or IS_VALID_TIMESTAMP().

Vitaly Burovoy, reviewed by Anastasia Lubennikova, and substantially
whacked around by me
13 files changed:
src/backend/utils/adt/date.c
src/backend/utils/adt/datetime.c
src/backend/utils/adt/formatting.c
src/backend/utils/adt/timestamp.c
src/include/datatype/timestamp.h
src/interfaces/ecpg/pgtypeslib/dt.h
src/interfaces/ecpg/pgtypeslib/timestamp.c
src/test/regress/expected/date.out
src/test/regress/expected/timestamp.out
src/test/regress/expected/timestamptz.out
src/test/regress/sql/date.sql
src/test/regress/sql/timestamp.sql
src/test/regress/sql/timestamptz.sql