Fujii Masao wrote: > On Tue, Oct 11, 2011 at 6:37 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > > On Mon, Oct 10, 2011 at 6:52 PM, Josh Berkus <j...@agliodbs.com> wrote: > > > >>> Tatsuo/Josh/Robert also discussed how recovery.conf can be used to > >>> provide parameters solely for recovery. That is difficult to do > >>> without causing all downstream tools to make major changes in the ways > >>> they supply parameters. > >> > >> Actually, this case is easily solved by an "include recovery.conf" > >> parameter. ?So it's a non-issue. > > > > That is what I've suggested and yes, doing that is straightforward. > > Even if we do that, you still need to modify the tool so that it can handle > the recovery trigger file. recovery.conf is used as just a configuration file > (not recovery trigger file at all). It's not renamed to recovery.done at the > end of recovery. If the tool depends on the renaming from recovery.conf > to recovery.done, it also would need to be modified. If the tool needs to > be changed anyway, why do you hesitate in changing it so that it adds > "include recovery.conf" into postgresql.conf automatically? > > Or you think that, to keep the backward compatibility completely, > recovery.conf should be used as not only a configuration file but also a > recovery trigger one and it should be renamed to recovery.done at > the end of recovery?
As much as I appreciate Simon's work in this area, I think we are still unclear if keeping backward-compatibility is worth the complexity required for future users. Historically we have been bold in changing postgresql.conf settings to improve clarity, and that approach has served us well. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
