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: <3D60B97C-5E80-4343-9CCF-390CD23B0E23@gmail.com>
Date: Mon, 17 Jul 2017 13:17:54 -0700
Cc: pgsql-hackers@postgreSQL.org
Content-Transfer-Encoding: 7bit
Message-Id: <3CD79F5D-DB73-4F2A-B698-44FF1930CB97@gmail.com>
References: <30691.1500156034@sss.pgh.pa.us>
 <3D60B97C-5E80-4343-9CCF-390CD23B0E23@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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

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.

Thanks!

mark


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