Re: More tzdb fun: POSIXRULES is being deprecated upstream
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-06-19T19:55:07Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > 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. The code delta is small enough that I don't foresee any real maintenance problem if we let the back branches differ from HEAD/v13 on this point. What I'm concerned about is that people depending on the existing behavior are likely to wake up one fine morning and discover that it's broken after a routine tzdata update. I think that it'd be a better user experience for them to see a release-note entry in a PG update release explaining that this will break and here's what to do to fix it. 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. regards, tom lane
Commits
-
Remove support for timezone "posixrules" file.
- ea57e531b948 14.0 landed
- 21aac2ff96e3 13.0 landed
-
Future-proof regression tests against possibly-missing posixrules file.
- 577dcf890cdb 13.0 landed
- 2c8ef9363db1 14.0 landed
- e7c183cd1fd1 11.9 landed
- b22ca7648b6f 12.4 landed
- 9496908d465e 9.6.19 landed
- 91e27a3e80b6 10.14 landed
- 34ef5863c77b 9.5.23 landed
-
Doc: document POSIX-style time zone specifications in full.
- 070f49005350 11.9 landed
- c10dc2d11791 13.0 landed
- 3b8210da32c4 12.4 landed
- a3235a53ae9f 14.0 landed
- 28fa0484efe9 10.14 landed
- 28589a8350d3 9.6.19 landed
- 089a63ec80e0 9.5.23 landed
-
Please find attached diffs for documentation and simple regression
- b2b6548c79eb 8.1.0 cited