Robert Haas <robertmh...@gmail.com> writes:
> On Sat, Jul 15, 2017 at 6:00 PM, Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
