aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistxlog.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2010-12-28 22:49:57 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2010-12-28 22:49:57 -0500
commitf2ba1e994c4d17dc3d4b8d48d3933c96d09127e1 (patch)
treed2a91f27c1537077ff456f315444b3aa20a0462a /src/backend/access/gist/gistxlog.c
parent31d2efaef507f280f4df895e1730a9ec8c31aa12 (diff)
downloadpostgresql-f2ba1e994c4d17dc3d4b8d48d3933c96d09127e1.tar.gz
postgresql-f2ba1e994c4d17dc3d4b8d48d3933c96d09127e1.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/access/gist/gistxlog.c')
0 files changed, 0 insertions, 0 deletions