> On Feb 24, 2019, at 13:44, Stephen Frost <sfr...@snowman.net> wrote:
>
> Right, and PG12 will be out for another *5* years beyond that, meaning
> people will have had 8.5 years to move from the exclusive API to the
> non-exclusive one.
The thing is that for 90% of installations, the clock will start ticking when
the deprecation. Until then, most of them are not going to feel any pressure
to make the change. Most installations have a lot of other things on their
minds. They have the option of not upgrading, and that will be the option a
lot of them take.
> Every one of the exclusive backups that was taken wasn't *safe*, and a
> crash during any of them (which we've certainly heard plenty about
> through various support channels over the years...) would have resulted
> in a failure to properly restart.
Most installations don't routinely encounter this. I know it happens, and it
is definitely a problem, but the field is not strewn with corpses here. The
new interface is unquestionably an improvement, but let's not get our messaging
amped up to the point that it hurts our credibility.
> No, I'm not saying that such backups are corrupted, *that* is an
> overstatement, but it isn't actually what I'm saying, just a strawman
> you've come up with to argue against.
That may not be what you are saying, but statements like "it *is* impossible to
do safe backups with the existing API" will be heard that way. Let's keep the
messaging we give users accurate.
> this isn't any different in that regard and I don't have
> sympathy for people who insist on saying that *this*, just *this* one
> API of *all* the ones we have simply *can't* be changed *ever*.
Sure, we can change anything. It's whether this particular deprecation is a
good idea.
> I'm not following here, at all... We're actually better, historically,
> about not changing SQL-level constructs than C-level APIs
That's my point. Calling this an "API" makes the change sound more routine
than it is. It's an "API" that a *lot* of installations depend on.
> I don't agree that simply documenting the issues with
> it is a sufficient solution to make us keep it.
Understood, but I think we need to document it no matter what.
--
-- Christophe Pettus
x...@thebuild.com
