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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Something for the TODO list: deprecating abstime andfriends
Дата
Msg-id 20171213080506.cwjkpcz3bkk6yz2u@alap3.anarazel.de
обсуждение исходный текст
Ответ на [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 andfriends
Re: [HACKERS] Something for the TODO list: deprecating abstime andfriends
Список pgsql-hackers
Hi,

On 2017-07-15 18:00:34 -0400, Tom Lane wrote:
> 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.

Hah, I'd completely missed this thread. But very recently arrived at the
the same conclusion, albeit for different reasons. Largely because the
code isn't very rigid about dealing with overflows.  I really don't want
to invest time in polishing up code that, as you say, doesn't really
have much of a usecase.


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

Yea, I think that's reasonable. I think it'd also be defensible to go to
a pure timestamptz rather than timestamptz(0). That's going to
negatively effect very few users...


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

Looking at the code I'd be pretty strongly inclined to scrap it.


Before I'd discovered this thread, I'd started to write up a
patch. Attached. It's clearly not fully done. Questions I'd while
hacking things up:
- what to do with contrib/spi/timetravel - I'd just removed it from the
  relevant Makefile for now.
- nabstime.c currently implements timeofday() which imo is a pretty
  weird function. I'd be quite inclined to remove it at the same time as
  this.

Greetings,

Andres Freund

Вложения

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: list partition constraint shape
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Something for the TODO list: deprecating abstime andfriends