Re: More tzdb fun: POSIXRULES is being deprecated upstream

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: More tzdb fun: POSIXRULES is being deprecated upstream
Дата
Msg-id 1754851.1592596507@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: More tzdb fun: POSIXRULES is being deprecated upstream  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: More tzdb fun: POSIXRULES is being deprecated upstream  (Robert Haas <robertmhaas@gmail.com>)
Re: More tzdb fun: POSIXRULES is being deprecated upstream  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: More tzdb fun: POSIXRULES is being deprecated upstream
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Parallel Seq Scan vs kernel read ahead