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

Reply via email to