Early discussions had difficulties because of the lack of config directories, include_if_exists and this patch. We now have the technical capability to meet every request. Circumstances have changed and outcomes may change also.
Thanks for the clarifications. The following questions are still unanswered:
1) If recovery.trigger and recovery.conf are specified. To which one the priority is given?
2) If both recovery.trigger and recovery.conf are used, let's imagine that the server removes recovery.trigger but fails in renaming recovery.conf but a reason or another. Isn't there a risk of inconsistency if both triggering methods are used at the same time?
3) Forcing a harcode of include_is_exists = 'recovery.conf' at the bottom of postgresql.conf doesn't look like a hack?
4) Based on your proposal, are all the parameters included in postgresql.conf.sample or not? Or only primary_conninfo, trigger_file and standby_mode?
