Thanks for the submission. I'm open to having better checks here to prevent cases like the ones mentioned in #12 . Did you pick the current min/max range arbitrarily? I think the range is well suited for most cases, but maybe it's too restrictive. Would it be difficult to support the full range of bigint from minimum value to maximum value or do you think it'd be too complicated with overflow checks?

Edit: Ah I see this may be quite complex in the addition with interval checks

timestamp9_recv would need a check added too, otherwise invalid values can be constructed from the binary libpq protocol

Did you pick the current min/max range arbitrarily? I think the range is well suited for most cases, but maybe it's too restrictive. Would it be difficult to support the full range of bigint from minimum value to maximum value or do you think it'd be too complicated with overflow checks?

Yes, I pick the min/max year arbitrarily, but pick the date 01-01 deliberately, since it's easy for validating the timestamp and that's what PostgreSQL do for the builtin timestamp range.

Based on your comment, I enlarge the value range to [1700-01-01 00:00:00.000000000 UTC+0, 2262-01-01 00:00:00.000000000 UTC+0) in my latest patch, because INT64_MIN corresponds to 1677-09-21 00:12:43.145224192 +0000 and INT64_MAX corresponds to 2262-04-11 23:47:16.854775807 +0000.

timestamp9_recv would need a check added too, otherwise invalid values can be constructed from the binary libpq protocol

Good catch! Thanks for pointing it out.

In my latest commit, I modified timestamp9.sql since we need to validate the range when doing the conversion from bigint to timestamp9.

I don't see it merged into 1.4.0.

Any plan to merge and release this PR? Thank you.