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

From: Mark Dilger <hornschnorter(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Something for the TODO list: deprecating abstime and friends
Date: 2017-07-17 19:54:31
Message-ID: 3D60B97C-5E80-4343-9CCF-390CD23B0E23@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 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.
> It's not too soon to start having a plan for that, especially seeing
> that it seems to take a decade or more for us to actually get rid
> of anything we've deprecated.
>
> Right offhand, I don't think there is any functionality in these
> types that isn't handled as well or better by timestamptz, interval,
> and tstzrange respectively.

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.

That said, I am fully aware that these are deprecated and expect you
will remove them, at which time I'll have to keep them in my tree
and politely refuse to merge in your change which removes them.

mark

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-07-17 20:09:04 Re: PgFDW connection invalidation by ALTER SERVER/ALTER USER MAPPING
Previous Message Tom Lane 2017-07-17 17:53:24 Re: Why have we got both largeobject and large_object test files?