Horton

Re: More tzdb fun: POSIXRULES is being deprecated upstream

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-06-19T19:41:21Z
Lists: pgsql-hackers 
On Fri, Jun 19, 2020 at 3:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Anyway, as I write this I'm kind of talking myself into the position
> that we should indeed back-patch this.  The apparent stability
> benefits of not doing so may be illusory, and if we back-patch then
> at least we get to document that there's a change.  But an argument
> could be made in the other direction too.

It's really unclear to me why we should back-patch this into
already-released branches. I grant your point that perhaps few people
will notice, and also that this might happen at some point the change
will be forced upon us. Nonetheless, we bill our back-branches as
being stable, which seems inconsistent with forcing a potentially
breaking change into them without a clear and pressing need. If you
commit this patch to master and v13, no already-release branches will
be affected immediately, and it's conceivable that some or even all of
the older branches will age out before the issue is forced. That would
be all to the good. And even if the issue is forced sooner rather than
later, how much do we really lose by waiting until we have that
problem in front of us?

I'm not in a position to judge how much additional maintenance
overhead would be imposed by not back-patching this at once, so if you
tell me that it's an intolerable burden, I can't really argue with
that. But if it's possible to take a wait-and-see attitude for the
time being, so much the better.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Remove support for timezone "posixrules" file.

  2. Future-proof regression tests against possibly-missing posixrules file.

  3. Doc: document POSIX-style time zone specifications in full.

  4. Please find attached diffs for documentation and simple regression