Simon Riggs <si...@2ndquadrant.com> writes: > ... The time to replace it is now and I > welcome that day and have already agreed to it.
Okay, so you do agree that eventually we want to be rid of recovery.conf? I think everyone else agrees on that. But if we are going to remove recovery.conf eventually, what is the benefit of postponing doing so? The pain is going to be inflicted sooner or later, and the longer we wait, the more third-party code there is likely to be that expects it to exist. If optionally reading it helped provide a smoother transition, then maybe there would be some point. But AFAICS having a temporary third behavior will just make things even more complicated, not less so, for third-party code that needs to cope with multiple versions. > The semantics are clear: recovery.conf is read first, then > postgresql.conf. It's easy to implement (1 line of code) and easy to > understand. It's not clear to me why the override order should be that way; I'd have expected the other way myself. So this isn't as open-and-shut as you think. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers