Moaaz Assali <ma5679@nyu.edu> writes:
> However, I don't see the issue with the INT64 -> UINT64 mapping. The
> current implementation results in integer overflows (errors instead after
> the recent patch) even for valid timestamps where the result of date_bin()
> is also another valid timestamp.
> On the other hand, the INT64 -> UINT64 mapping solves this issue and allows
> the input of any valid source and origin timestamps as long as the stride
> chosen doesn't output invalid timestamps that cannot be represented by
> Timestamp(tz) type anyways. Since all INT64 values can be mapped 1-to-1 in
> UINT64, I don't see where the problem is.
What I don't like about it is that it's complicated (and you didn't
make any effort whatsoever to make the code intelligible or self-
documenting), and that complication has zero real-world benefit.
The only way to hit an overflow in this subtraction is with dates
well beyond 200000 AD. If you are actually dealing with such dates
(maybe you're an astronomer or a geologist), then timestamp[tz] isn't
the data type for you, because you probably need orders of magnitude
wider range than it's got.
Now I'll freely admit that the pg_xxx_yyy_overflow() functions are
notationally klugy, but they're well documented and they're something
that people would need to understand anyway for a lot of other places
in Postgres. So I think there's less cognitive load for readers of
the code in the let's-throw-an-error approach than in writing one-off
magic code that in the end can avoid only one of the three possible
overflow cases in this function.
regards, tom lane
