From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "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-16 16:32:57 |
Message-ID: | CA+TgmobF9dJdU8tR2QdCvntZ29KDaC5Kv2ZgQ=2da3Ftpm82eg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jul 15, 2017 at 6:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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. And they're basically undocumented
> except for a sort-of deprecation notice just above section 8.5.1.
> So my inclination is to remove them rather than try to upgrade them
> in any way. However, we'd have to do something about:
>
> * The legacy system views pg_shadow and pg_user have abstime columns.
> Experimentation suggests that we could convert those to timestamptz(0)
> and the output format wouldn't change, so maybe that's a good enough
> fix there.
+1 for doing that in v11.
> * contrib/spi/timetravel depends on abstime columns to represent what
> would nowadays be better done as a tstzrange. I'd have thought we
> could maybe toss that example module overboard, but we just today got
> a question about its usage, so I'm afraid it's not quite dead yet.
> What shall we do with that?
No idea. I think if nobody's willing to come up with a plan for this
and do the work to implement it, we should just remove the module when
we get closer to 2038. But I don't think we have to make that
decision for at least another 5 years or so.
> While it's too late in the v10 cycle to do anything very meaningful
> about this now, I am tempted to strengthen the deprecation notice's
> wording from "might disappear" to "will disappear".
-1 for changing that; such predictions often turn out to be wrong.
> And it's not good
> that the documentation of contrib/spi/timetravel contains nothing
> whatever pointing out the lack of future-proof-ness of abstime.
+1 for fixing that, though. Maybe we can find a wording that says in
effect "this module will need to be removed or fixed sometime not too
many years from now; if you care about keeping it around, maybe you
should volunteer to do the necessary fixing".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-07-16 17:03:52 | Re: Something for the TODO list: deprecating abstime and friends |
Previous Message | Magnus Hagander | 2017-07-16 12:01:57 | Re: More flexible LDAP auth search filters? |