On Thu, Oct 21, 2021 at 4:29 PM Stephen Frost <sfrost@snowman.net> wrote: > restore_command used to be in recovery.conf, which disappeared with v12 > and it now has to go into postgresql.auto.conf or postgresql.conf. > > That's a huge breaking change.
Not in the same sense. Moving the functionality to a different configuration file can and probably did cause a lot of problems for people, but the same basic functionality was still available.
Yeah.
And as a bonus it got a bunch of people to upgrade their backup software that suddenly stopped working. Or in some case, to install backup software instead of using the hand-rolled scripts. So there were some good side-effects specifically to breaking it as well.
(Also, I'm pretty sure that the recovery.conf changes would have happened years earlier if there hadn't been backward compatibility concerns, from Simon in particular. So saying that there was "hardly any complaint raised" in that case doesn't seem to me to be entirely accurate.)
> > Also, more to the point, when there's a need to break backward > > compatibility in order to get some improvement, it's worth > > considering, but here there just isn't. > > There won't be any thought towards a backwards-incompatible capability > if everyone is saying that we can't possibly break it. That's why I was > commenting on it.
I can't speak for anyone else, but that is not what I am saying. I am open to the idea of breaking it if we thereby get some valuable benefit which cannot be obtained otherwise. But Nathan has now implemented something which, from the sound of it, will allow us to obtain all of the available benefits with no incompatibilities. If we think of additional benefits that we cannot obtain without incompatibilities, then we can consider that situation when it arises. In the meantime, there's no need to go looking for reasons to break stuff that works in existing releases.
