diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2010-12-28 22:49:57 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2010-12-28 22:50:51 -0500 |
commit | 1fa37ac25d6aa26443e47f96aafe87c3339ebc18 (patch) | |
tree | 96c2a8a4cda9b5d23f5f12a2787111cbb7d6d546 /src/backend/utils/adt/arrayfuncs.c | |
parent | 6dca2601294f9604b84f46980b84d02c0a36836a (diff) | |
download | postgresql-1fa37ac25d6aa26443e47f96aafe87c3339ebc18.tar.gz postgresql-1fa37ac25d6aa26443e47f96aafe87c3339ebc18.zip |
Avoid unexpected conversion overflow in planner for distant date values.
The "date" type supports a wider range of dates than int64 timestamps do.
However, there is pre-int64-timestamp code in the planner that assumes that
all date values can be converted to timestamp with impunity. Fortunately,
what we really need out of the conversion is always a double (float8)
value; so even when the date is out of timestamp's range it's possible to
produce a sane answer. All we need is a code path that doesn't try to
force the result into int64. Per trouble report from David Rericha.
Back-patch to all supported versions. Although this is surely a corner
case, there's not much point in advertising a date range wider than
timestamp's if we will choke on such values in unexpected places.
Diffstat (limited to 'src/backend/utils/adt/arrayfuncs.c')
0 files changed, 0 insertions, 0 deletions