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

Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
>> On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnorter(at)gmail(dot)com> wrote:
> On Jul 15, 2017, at 3:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> The types abstime, reltime, and tinterval need to go away, or be
>>> reimplemented, sometime well before 2038 when they will overflow.

>> These types provide a 4-byte datatype for storing real-world second
>> precision timestamps, as occur in many log files. Forcing people to
>> switch to timestamp or timestamptz will incur a 4 byte per row
>> penalty. In my own builds, I have changed the epoch on these so
>> they won't wrap until sometime after 2100 C.E. I see little point in
>> switching to an 8-byte millisecond precision datatype when a perfectly
>> good 4-byte second precision datatype already serves the purpose.

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.

But we're already past the point where it would be time to make the
first such switch, if we're gonna do it. So I'd like to see somebody
step up to the plate sooner not later.

I'd be inclined to toss reltime and tinterval overboard in any case.

> Oh, and if you could be so kind, please remove them in a commit that
> does nothing else. It's much easier to skip the commit that way.

We doubtless would do that, but you're fooling yourself if you imagine
that you can maintain such a fork for long while still tracking the
community version otherwise. Once those hand-assigned OIDs are free
they'll soon be absorbed by future feature patches, and then you'll
have enormous merge problems.

regards, tom lane