On Wed, Dec 19, 2012 at 10:34:14PM +0000, Simon Riggs wrote: > On 19 December 2012 22:19, Joshua Berkus <j...@agliodbs.com> wrote: > > > >> It stalled because the patch author decided not to implement the > >> request to detect recovery.conf in data directory, which allows > >> backwards compatibility. > > > > Well, I don't think we had agreement on how important backwards > > compatibility for recovery.conf was, particularly not on the whole > > recovery.conf/recovery.done functionality and the wierd formatting of > > recovery.conf. > > As ever, we spent much energy on debating backwards compatibility > rather than just solving the problem it posed, which is fairly easy to > solve.
Let me also add that I am tired of having recovery.conf improvement stalled by backward compatibility concerns. At this point, let's just trash recovery.conf backward compatibility and move on. And I don't want to hear complaints about tool breakage either. These are external tools, not shipped with community Postgres, and they will just have to adjust. I will be glad to beat all complainants into the ground for the good of the community. ;-) We just can't operate like this, and if we allowed these things to block us in the past, Postgres would be a royal mess today! At this point backward compatibility has paralized us from fixing a recovery.conf API that everyone agrees is non-optimal, and this has gone on for multiple major releases. I don't care what we have to do, just clean this up for 9.3! -- 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