Re: Something for the TODO list: deprecating abstime and friends

Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
>> On Jul 17, 2017, at 2:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Well, if you or somebody is willing to do the legwork, I'd be on board
>> with a plan that says that every 68 years we redefine the origin of
>> abstime. I imagine it could be done so that currently-stored abstime
>> values retain their present meaning as long as they're not too old.
>> For example the initial change would toss abstimes before 1970 overboard,
>> repurposing that range of values as being 2038-2106, but values between
>> 1970 and 2038 still mean the same as they do today. If anybody still
>> cares in circa 2085, we toss 1970-2038 overboard and move the origin
>> again, lather rinse repeat.

> Assuming other members of the community would not object to such
> a plan, I'd be willing to step up to that plate.

So, thinking about how that would actually work ... the thing to do in
order to preserve existing on-disk values is to alternate between signed
and unsigned interpretations of abstimes. That is, right now, abstime
is signed with origin 1970. The conversion I'm arguing we should make
real soon now is to unsigned with origin 1970. If the project lives
so long, in circa 70 years we'd switch it to signed with origin 2106.
Yadda yadda.

Now, this should mostly work conveniently, except that we have
+/-infinity (NOEND_ABSTIME/NOSTART_ABSTIME) to deal with. Those
are nicely positioned at the ends of the signed range so that
abstime_cmp_internal() doesn't need to treat them specially.
In an unsigned world they'd be smack in the middle of the range.
We could certainly teach abstime_cmp_internal to special-case them
and deliver logically correct results, but there's a bigger problem:
those will correspond to two seconds in January 2038 that will need
to be representable when the time comes. Maybe we can make that
work by defining the values past 2038 as being two seconds less than
you might otherwise expect, but I bet it's gonna be messy. It might
be saner to just desupport +/-infinity for abstime.

The same goes for INVALID_ABSTIME, which doesn't have any clear
use-case that I know of, and is certainly not documented.

regards, tom lane