On Thu, Dec 13, 2018 at 2:29 PM David Steele <david@pgmasters.net> wrote:
> Good question.
>
> 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?
>
> I agree it's not very cool to break code for users who actually *did*
> migrate to non-exclusive backups.
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.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
