Re: More tzdb fun: POSIXRULES is being deprecated upstream

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

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-06-19 20:00:07 Re: Parallel Seq Scan vs kernel read ahead
Previous Message Robert Haas 2020-06-19 19:41:21 Re: More tzdb fun: POSIXRULES is being deprecated upstream