Обсуждение: 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