Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Something for the TODO list: deprecating abstime and friends |
Дата | |
Msg-id | CA+TgmobF9dJdU8tR2QdCvntZ29KDaC5Kv2ZgQ=2da3Ftpm82eg@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] Something for the TODO list: deprecating abstime and friends (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
|
Список | pgsql-hackers |
On Sat, Jul 15, 2017 at 6:00 PM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: