Re: Remove Deprecated Exclusive Backup Mode - Mailing list pgsql-hackers

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Dec 13, 2018 at 2:29 PM David Steele <david@pgmasters.net> wrote:
> > We could leave the third parameter (changing the default to false) and
> > error if it has any value but false.  It's a bit ugly but it does
> > maintain compatibility with the current non-exclusive backup interface.
> >  And, the third parameter would never need to be specified unless we add
> > a fourth.
> >
> > Or we could add a new function and deprecate this one -- but what to
> > call it?

... and would people really realize that they have to do more than just
change the function name?  I'm not sure.

> > I agree it's not very cool to break code for users who actually *did*
> > migrate to non-exclusive backups.

This bothers me much less.  We change our APIs between major releases
from time-to-time and people need to update their code to handle that.

> Uh, yeah.  If you do that, you're not just forcing people off the old
> interface -- you're making *everybody* update their stuff again.  And
> having to have conditional logic to handle different releases presents
> its own set of dangers. IMHO, the biggest enemy in this area BY FAR is
> human error, not the details of how the interface works. No amount of
> providing a better-designed interface will compensate for the
> confusion factor involved in changing it.

I don't agree with the argument that conditional logic for different
releases is an issue- we already require people to have that all over
the place and, while it's a bit annoying, it's part and parcel for
working with multiple major versions of PG.

> My vote is ... when we actually deprecate this, change nothing at the
> SQL level initially, but just throw an error if the "exclusive"
> argument isn't false:

> ERROR: exclusive backup mode is no longer supported

> That will require everyone to use the three-argument form of
> pg_start_backup(), but I think that's good, because if we accept the
> one and two argument forms, how do we actually know that the user
> updated their code?  If you want to actually force people to switch to
> the non-exclusive mode, you have to make sure that anything that might
> be a residual request for exclusive backup mode errors out.  If the
> same SQL just does something different, the user might fail to notice.

This is an argument that I can agree with though.  We certainly don't
want existing users of the exclusive mode to think "everything is fine!"
after it's been ripped out.  I hate having to leave old API cruft around
like an argument that's required to be passed in and required to have a
specific value but it does seem the best way to make it extremely clear
to users of the exclusive mode that they really have to adjust their
code.

Perhaps in some future version we'll redefine the API more broadly and
be able to rip out this API entirely, throwing away such old cruft as we
do it, but until then I think we can live with it.

Thanks!

Stephen