On 3/1/22 11:32, Nathan Bossart wrote:
On Tue, Mar 01, 2022 at 11:09:13AM -0500, Chapman Flack wrote:
On 03/01/22 09:44, David Steele wrote:
Personally, I am in favor of removing it. We change/rename
functions/tables/views when we need to, and this happens in almost every
release.
For clarification, is that a suggestion to remove the 'exclusive' parameter
in some later release, after using this release to default it to false and
reject calls with true?
My suggestion was to remove it in v15. My impression is that David and
Stephen agree, but I could be misinterpreting their responses.
I agree and I'm pretty sure Stephen does as well.
That way, at least, there would be a period of time where procedures
that currently work (by passing exclusive => false) would continue to work,
and could be adapted as time permits by removing that argument, with no
behavioral change.
I'm not sure if there's any advantage to kicking the can down the road. At
some point, we'll need to break existing backup scripts. Will we be more
prepared to do that in v17 than we are now? We could maintain two sets of
functions for a few releases and make it really clear in the documentation
that pg_start/stop_backup() are going to be removed soon (and always emit a
WARNING when they are used). Would that address your concerns?
I think people are going to complain no matter what. If scripts are
being maintained changing the name is not a big deal (though moving from
exclusive to non-exclusive may be). If they aren't being maintained then
they'll just blow up a few versions down the road when we remove the
compatibility functions.
Regards,
-David
