"Kruus, Robert ENV" <robert.kr...@gov.sk.ca> writes:
>> Hmph. Is your installation built with --enable-integer-datetimes?
> Yes it is 'on'.
On further probing, I can make it happen with float datetimes too,
if I throw enough fractional nines in there:
regression=# select '1999-08-06
00:12:57.999999999999999999999999999900'::timestamptz;
ERROR: date/time field value out of range: "1999-08-06
00:12:57.999999999999999999999999999900"
The problem seems to be here:
/* do a sanity check */
#ifdef HAVE_INT64_TIMESTAMP
if (tm->tm_hour < 0 || tm->tm_min < 0 || tm->tm_min > 59 ||
tm->tm_sec < 0 || tm->tm_sec > 60 || *fsec < INT64CONST(0) ||
*fsec >= USECS_PER_SEC)
return DTERR_FIELD_OVERFLOW;
#else
if (tm->tm_hour < 0 || tm->tm_min < 0 || tm->tm_min > 59 ||
tm->tm_sec < 0 || tm->tm_sec > 60 || *fsec < 0 || *fsec >= 1)
return DTERR_FIELD_OVERFLOW;
#endif
With enough nines, the fsec value is going to round up to 1.0 (float
case) or USECS_PER_SEC (int case). So I think that this check ought
to allow, not exclude, the boundary value. And then we need to be
sure the subsequent code adds the values together properly, but that
probably happens okay already.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
