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

> On Jul 18, 2017, at 9:13 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
> 
>> 
>> On Jul 17, 2017, at 2:34 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
>> 
>>> 
>>> On Jul 17, 2017, at 2:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 
>>> Mark Dilger <hornschnorter@gmail.com> writes:
>>>>> On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
>>>> On Jul 15, 2017, at 3:00 PM, Tom Lane <tgl@sss.pgh.pa.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.
>> 
>> Assuming other members of the community would not object to such
>> a plan, I'd be willing to step up to that plate.  I'll wait a respectable time,
>> maybe until tomorrow, to allow others to speak up.
> 
> There was not much conversation about this, so I went ahead with what
> I think makes a logical first step.  The attached patch removes the tinterval
> datatype from the sources.
> 
> I intend to remove reltime next, and then make the changes to abstime in
> a third patch.

As predicted, this second patch (which should be applied *after* the prior
tinterval_abatement patch) removes the reltime datatype from the sources.

mark