Re: More tzdb fun: POSIXRULES is being deprecated upstream

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: More tzdb fun: POSIXRULES is being deprecated upstream
Date: 2020-06-25 13:08:48
Message-ID: caf69528-f074-19c1-08c0-6d50e61bf904@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-06-19 21:55, Tom Lane wrote:
> Yeah, we can do nothing in the back branches and hope that that doesn't
> happen for the remaining lifespan of v12. But I wonder whether that
> doesn't amount to sticking our heads in the sand.
>
> I suppose it'd be possible to have a release-note entry in the back
> branches that isn't tied to any actual code change on our part, but just
> warns that such a tzdata change might happen at some unpredictable future
> time. That feels weird and squishy though; and people would likely have
> forgotten it by the time the change actually hits them.

In my mind, this isn't really that different from other external
libraries making API changes. But we are not going to forcibly remove
Python 2 support in PostgreSQL 9.6 just because it's no longer supported
upstream. If Debian or RHEL $veryold want to keep maintaining Python 2,
they are free to do so, and users thereof are free to continue using it.
Similarly, Debian or RHEL $veryold are surely not going to drop a
whole class of time zone codes from their stable distribution just
because upstream is phasing it out.

What you are saying is, instead of the OS dropping POSIXRULES support,
it would be better if we dropped it first and release-noted that.
However, I don't agree with the premise of that. OSes with long-term
support aren't going to drop it.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Inoue, Hiroshi 2020-06-25 13:14:00 Re: Removal of currtid()/currtid2() and some table AM cleanup
Previous Message James Coleman 2020-06-25 12:41:43 Re: Open Item: Should non-text EXPLAIN always show properties?