> On Jul 17, 2017, at 3:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >>> On Jul 17, 2017, at 2:14 PM, Tom Lane <t...@sss.pgh.pa.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.
I use the abstime type in some catalog tables, and if I allowed those fields to have something equivalent to NULL, which I do not, I would need INVALID_ABSTIME, since NULL is not allowed in the constant header of a catalog table. I wonder if old versions of postgres had catalog tables with abstime used in this way? Other than that, I can't think of a reason to use INVALID_ABSTIME. mark -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers