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

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
Дата
Msg-id 63B7E72B-4B44-437D-91BE-80782A63BA7E@gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Something for the TODO list: deprecating abstime and friends  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> On Jul 17, 2017, at 3:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Mark Dilger <hornschnorter@gmail.com> writes:
>> On Jul 17, 2017, at 3:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Now, this should mostly work conveniently, except that we have
>>> +/-infinity (NOEND_ABSTIME/NOSTART_ABSTIME) to deal with ... It might
>>> be saner to just desupport +/-infinity for abstime.
>
>> I don't use those values, so it is no matter to me if we desupport them.  It
>> seems a bit pointless, though, because we still have to handle legacy
>> values that we encounter.  I assume some folks will have those values in
>> their tables when they upgrade.
>
> Well, some folks will also have pre-1970 dates in their tables, no?
> We're just blowing those off.  They'll print out as some post-2038
> date or other, and too bad.
>
> Basically, the direction this is going in is that abstime will become
> an officially supported type, but its range of supported values is "not
> too many decades either way from now".  If you are using it to store
> very old dates then You're Doing It Wrong, and eventually you'll get
> bitten.  Given that contract, I don't see a place for +/-infinity.

Works for me.

mark




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
Следующее
От: Mark Rofail
Дата:
Сообщение: Re: [HACKERS] GSoC 2017: Foreign Key Arrays