[HACKERS] Something for the TODO list: deprecating abstime and friends

Поиск
Список
Период
Сортировка
От Tom Lane
Тема [HACKERS] Something for the TODO list: deprecating abstime and friends
Дата
Msg-id 30691.1500156034@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: [HACKERS] Something for the TODO list: deprecating abstime and friends  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] Something for the TODO list: deprecating abstime and friends  (Greg Stark <stark@mit.edu>)
Re: [HACKERS] Something for the TODO list: deprecating abstime and friends  (Mark Dilger <hornschnorter@gmail.com>)
Re: [HACKERS] Something for the TODO list: deprecating abstime andfriends  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
The types abstime, reltime, and tinterval need to go away, or be
reimplemented, sometime well before 2038 when they will overflow.
It's not too soon to start having a plan for that, especially seeing
that it seems to take a decade or more for us to actually get rid
of anything we've deprecated.

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.

* 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?

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".  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.

Thoughts?
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] More race conditions in logical replication
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: [HACKERS] Pluggable storage