Re: [HACKERS] Something for the TODO list: deprecating abstime and friends - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
Date
Msg-id E8A4CF38-002A-423D-94C6-E7B6463EA201@gmail.com
Whole thread Raw
In response to Re: [HACKERS] Something for the TODO list: deprecating abstime and friends  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
List pgsql-hackers
> On Jul 19, 2017, at 10:23 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 
> On Wed, Jul 19, 2017 at 1:12 PM, Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash
Next
From: Mark Dilger
Date:
Subject: Re: [HACKERS] Something for the TODO list: deprecating abstime and friends