> On Jul 18, 2017, at 9:13 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > >> >> On Jul 17, 2017, at 2:34 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >> >>> >>> On Jul 17, 2017, at 2:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> >>> Mark Dilger <hornschnor...@gmail.com> writes: >>>>> On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >>>> On Jul 15, 2017, at 3:00 PM, Tom Lane <t...@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
Description: Binary data
-- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers