On Wed, Dec 19, 2012 at 07:32:33PM -0500, Robert Haas wrote: > On Wed, Dec 19, 2012 at 5:34 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > > As ever, we spent much energy on debating backwards compatibility > > rather than just solving the problem it posed, which is fairly easy to > > solve. > > I'm still of the opinion (as were a lot of people on the previous > thread, IIRC) that just making them GUCs and throwing backward > compatibility under the bus is acceptable in this case. Changes that > break application code are anathema to me, because people can have a > LOT of application code and updating it can be REALLY hard. The same > cannot be said about recovery.conf - you have at most one of those per > standby, and if it needs to be changed in some way, you can do it with > a very small Perl script. Yes, third-party tools will need to be > updated; that is surely a downside, but I think it might be a > tolerable one in this case.
Agreed. We have always has a more lax requirement of changing the Postgres administration interface. I am not saying to ignore backward compatibility, but future admin interface clarity overrules backward compatibility in most cases. If people are really worried about this, they can write a Perl script to convert from the old to new format. -- 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