> On Feb 24, 2019, at 13:00, Stephen Frost <sfr...@snowman.net> wrote:
>
> No, it *hasn't* been the only backup API for a long time- that was only
> true up until 9.6 was released, since then we've had both, and it's made
> everything a downright mess because of exactly these arguments.
9.6 has been out for about 2.5 years. How long was the old version of
pg_start_backup() the only interface? Considerably longer.
> Yes, it *is* impossible to do safe backups with the existing API.
That's an overstatement. "The existing interface has failure conditions that
are hard to work around" is true. Saying "it's impossible to do safe backups"
implies that no pre-9.6 system has ever been backed up. If we take that line,
it's just going to create a "Oh, come *on*" reaction from users.
> What I'll say
> is that they'll have over 5 years to adjust those scripts and I don't
> see an issue with that.
That's not quite the situation. What they will have is a choice between
upgrading, and or their existing scripts continuing to work. That choice will
start ticking the instant a release without the old interface comes out. The
back-pressure on upgrading is already very high; this is going to put a lot of
installations into a bind, and a lot will make the decision not to upgrade
because of that.
> *ALL* of our APIs are declared non-stable between major releases.
> That's why we have *major* and *minor* releases.
I note that a word game is being played here. We're calling pg_start_backup()
"an API", as if it is the same as, say, the GiST C API, but it's a SQL level
construct. SQL level constructs are not promises we need to keep forever, of
course, but they're not the same class of promise as a C API.
> Sure, it'd be nice if someone would fix it to list out the problems with
> the exclusive API, but that requires someone wanting to spend time on
> it.
I'll take a turn at it.
--
-- Christophe Pettus
x...@thebuild.com
