Обсуждение: 7.2 and current timestamp bug?

CREATE TABLE t (ts timestamp);
CREATE
INSERT INTO t VALUES ('2465001-01-01 00:00:00');
INSERT 16563 1
SELECT * from t;
psql:/home/t-ishii/tmp/datebug.sql:4: ERROR:  Unable to format timestamp with time zone; internal coding error

Shouldn't timestamp_in detect the invalid timestamp value when it is
inserted?
--
Tatsuo Ishii

Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> Shouldn't timestamp_in detect the invalid timestamp value when it is
> inserted?

Yeah.  A simpler test case is

regression=# select '2465001-01-01 00:00:00'::timestamp;
ERROR:  Unable to format timestamp with time zone; internal coding error

IMHO the IS_VALID_JULIAN() macro ought to test for out-of-range in the
forward direction as well as rearward.  The immediate problem in this
example is that date2j() overflows --- silently --- producing a negative
result which later confuses timestamp2tm.  We could limit the allowed
range of Julian dates to prevent that.

Another possibility is to allow date2j and j2date to pass/return double
instead of int, but that is a larger change and probably not very safe
to apply for 7.2.1.

Thomas, your thoughts?
        regards, tom lane

...
> Another possibility is to allow date2j and j2date to pass/return double
> instead of int, but that is a larger change and probably not very safe
> to apply for 7.2.1.

Pretty sure that j2date() relies on integer math behaviors to work. But
I haven't looked at it in quite a while. And it probably isn't worth the
effort to change things around. Limiting the date range a little works
for me. Lots of DBs allow only four digit years...

> Thomas, your thoughts?

Hmm. Let's yell at Tatsuo for trying silly dates ;)
                  - Thomas

Thomas Lockhart <lockhart@fourpalms.org> writes:
> Limiting the date range a little works
> for me. Lots of DBs allow only four digit years...

Fine with me.  Will you make the change?
        regards, tom lane