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-19 04:13:10 |
Message-ID: | BDA0815D-CFCE-4887-9069-FF488CC1648A@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Jul 17, 2017, at 2:34 PM, Mark Dilger <hornschnorter(at)gmail(dot)com> wrote:
>
>>
>> On Jul 17, 2017, at 2:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
>>>> On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnorter(at)gmail(dot)com> wrote:
>>> 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.
>>
>>>> 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.
mark
Attachment | Content-Type | Size |
---|---|---|
tinterval_abatement.patch.1 | application/octet-stream | 75.7 KB |
unknown_filename | text/plain | 2 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Rafia Sabih | 2017-07-19 04:24:12 | Re: Partition-wise join for join between (declaratively) partitioned tables |
Previous Message | Craig Ringer | 2017-07-19 01:47:07 | Re: [GENERAL] huge RAM use in multi-command ALTER of table heirarchy |