Reject nonzero day fields in AT TIME ZONE INTERVAL functions.

It's not sensible for an interval that's used as a time zone value to be
larger than a day.  When we changed the interval type to contain a separate
day field, check_timezone() was adjusted to reject nonzero day values, but
timetz_izone(), timestamp_izone(), and timestamptz_izone() evidently were
overlooked.

While at it, make the error messages for these three cases consistent.
This commit is contained in:
Tom Lane 2013-01-31 12:12:23 -05:00
parent bfb8a8d381
commit 9afc58396a
2 changed files with 6 additions and 6 deletions

View File

@ -2696,10 +2696,10 @@ timetz_izone(PG_FUNCTION_ARGS)
TimeTzADT *result;
int tz;
if (zone->month != 0)
if (zone->month != 0 || zone->day != 0)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("\"interval\" time zone \"%s\" not valid",
errmsg("interval time zone \"%s\" must not include months or days",
DatumGetCString(DirectFunctionCall1(interval_out,
PointerGetDatum(zone))))));

View File

@ -4604,10 +4604,10 @@ timestamp_izone(PG_FUNCTION_ARGS)
if (TIMESTAMP_NOT_FINITE(timestamp))
PG_RETURN_TIMESTAMPTZ(timestamp);
if (zone->month != 0)
if (zone->month != 0 || zone->day != 0)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("interval time zone \"%s\" must not specify month",
errmsg("interval time zone \"%s\" must not include months or days",
DatumGetCString(DirectFunctionCall1(interval_out,
PointerGetDatum(zone))))));
@ -4777,10 +4777,10 @@ timestamptz_izone(PG_FUNCTION_ARGS)
if (TIMESTAMP_NOT_FINITE(timestamp))
PG_RETURN_TIMESTAMP(timestamp);
if (zone->month != 0)
if (zone->month != 0 || zone->day != 0)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("interval time zone \"%s\" must not specify month",
errmsg("interval time zone \"%s\" must not include months or days",
DatumGetCString(DirectFunctionCall1(interval_out,
PointerGetDatum(zone))))));