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

From: Mark Dilger <hornschnorter(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Something for the TODO list: deprecating abstime and friends
Date: 2017-07-19 19:26:43
Message-ID: E8A4CF38-002A-423D-94C6-E7B6463EA201@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On Jul 19, 2017, at 10:23 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, Jul 19, 2017 at 1:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Doesn't this plan amount to breaking pg_upgrade compatibility and
>>> hoping that nobody notice?
>>
>> Well, what we'd need to do is document that the type is only meant to be
>> used to store dates within say +/- 30 years from current time. As long
>> as people adhere to that use-case, the proposal would work conveniently
>> long into the future ...
>
> Typically, when you try to store an out-of-range value in PostgreSQL,
> you get an ERROR, and that's one of the selling points of PostgreSQL.
> PostgreSQL users regularly beat up other projects for, say, allowing
> 0000-00-00 to be considered a valid date, or any similar perceived
> laxity in enforcing data consistency. I don't like the idea that we
> can just deviate from that principle whenever adhering to it is too
> much work.

I don't see the relevance of this statement. I am not planning to allow
abstime data that is outside the range of the new epoch. Attempts to
cast strings like '1962-07-07 01:02:03' to abstime would draw an
exception with a suitably informative message.

Now, the objection to having on-disk data automagically change meaning
is concerning, and I was particularly unsatisfied with the idea that
NOSTART_ABSTIME and NOEND_ABSTIME would suddenly be
reinterpreted as seconds in the year 2068, which is why I made mention
of it upthread. I was less concerned with dates prior to 1970 being
reinterpreted, though it is hard to justify why that bothers me less.

>> I'd definitely be on board with just dropping the type altogether despite
>> Mark's concern.
>
> Then I vote for that option.

I was somewhat surprised when Tom was onboard with the idea of keeping
abstime around (for my benefit). My original post was in response to his
statement that, right offhand, he couldn't think of any use for abstime that
wasn't handled better by timestamptz (paraphrase), and so I said that
improving storage efficiency was such a use. I maintain that position. The
abstime type is a good and useful type, and we will lose that use when we
discard it. Those who feel otherwise might like to also argue for dropping
float4 because float8 does all the same stuff better.

mark

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2017-07-19 19:37:09 Re: Something for the TODO list: deprecating abstime and friends
Previous Message Alvaro Herrera 2017-07-19 19:22:16 Re: [TRAP: FailedAssertion] causing server to crash