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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
Дата
Msg-id 5897.1500224632@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  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Jul 15, 2017 at 6:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> * 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.

The plan I'd tentatively suggest is to just s/abstime/timestamptz/g
in the timetravel module, something that would be unlikely to take more
than an hour's work.  If anyone was actually using it in production
they'd have to do some ALTER COLUMN TYPE changes before the trigger
would work again ... but that would get forced on them eventually
anyway.  Yup, you could turn this molehill into a mountain of work
if you wanted to have a more friendly transition, but I don't see
anyone putting in that much effort.

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

Those types will definitely fail for all use-cases in 2038, and for
many use-cases significantly before that; there's no uncertainty in that
prediction.  The only way they aren't going to disappear before 2038 is
if the project is defunct first, or if somebody is sufficiently concerned
with having an easier migration path that they are willing to design and
implement one.  I don't believe any of the usual suspects are going to do
that.  But if there's somebody who would care enough to de-lurk and make
it happen, they'd be much more likely to do so soon enough if there's some
advance warning in the docs.  Or in other words, I don't want to go from
"might disappear" in vN to gone in vN+1 with no intermediate state.
        regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
Следующее
От: "Mengxing Liu"
Дата:
Сообщение: [HACKERS] [GSOC][weekly report 6] Eliminate O(N^2) scaling from rw-conflicttracking in serializable transactions