> 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.
>> 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.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: