On Thu, Dec 13, 2018 at 2:29 PM David Steele <da...@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
