From d5b2587c20854044277c9616b8582b5f1f19d197 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 28 Dec 2010 22:49:57 -0500 Subject: 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. --- src/backend/utils/adt/selfuncs.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'src/backend/utils/adt/selfuncs.c') diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c index 3d60885a795..38a8a89ad3c 100644 --- a/src/backend/utils/adt/selfuncs.c +++ b/src/backend/utils/adt/selfuncs.c @@ -3796,8 +3796,7 @@ convert_timevalue_to_scalar(Datum value, Oid typid) return DatumGetTimestamp(DirectFunctionCall1(abstime_timestamp, value)); case DATEOID: - return DatumGetTimestamp(DirectFunctionCall1(date_timestamp, - value)); + return date2timestamp_no_overflow(DatumGetDateADT(value)); case INTERVALOID: { Interval *interval = DatumGetIntervalP(value); -- cgit v1.2.3