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