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