Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Something for the TODO list: deprecating abstime and friends
From: Mark Dilger <hornschnorter@gmail.com>
In-Reply-To: <12814.1500326041@sss.pgh.pa.us>
Date: Mon, 17 Jul 2017 14:34:58 -0700
Cc: pgsql-hackers@postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F148151A-AC66-40E6-981F-0B12A2149355@gmail.com>
References: <30691.1500156034@sss.pgh.pa.us>
 <3D60B97C-5E80-4343-9CCF-390CD23B0E23@gmail.com>
 <3CD79F5D-DB73-4F2A-B698-44FF1930CB97@gmail.com>
 <12814.1500326041@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


> On Jul 17, 2017, at 2:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> Mark Dilger <hornschnorter@gmail.com> writes:
>>> On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnorter@gmail.com> wro=
te:
>> 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.
>=20
>>> 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.
>=20
> 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.
>=20
> 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 t=
ime,
maybe until tomorrow, to allow others to speak up.

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

Yeah, I don't use those either, preferring to cast abstime to timestamp
(or timestamptz) prior to doing any math on them.

>=20
>> 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.
>=20
> 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.

Oh, not so much.  Knowing that they were going to be deprecated, I
already moved the Oids for these to something higher than 10000.  In
my own builds, the Oid generator does not assign Oids lower than 65536,
which leaves room for me to assign in the 10000-65535 range without
merge headaches.  It would, however, be simpler if the types did not
go away, as that would cause minor merge headaches elsewhere, such
as in the regression tests.

mark


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers