Re: Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 3:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
>> On Jul 17, 2017, at 3:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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