Re: Feature Request: pg_replication_master() - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Feature Request: pg_replication_master()
Date
Msg-id CA+TgmoYe=+uACJufWUuhEA+qDafM09Q+-yo=0ZzFCiQdStARNg@mail.gmail.com
Whole thread Raw
In response to Re: Feature Request: pg_replication_master()  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Feature Request: pg_replication_master()
List pgsql-hackers
On Wed, Dec 19, 2012 at 5:34 PM, Simon Riggs <simon@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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Review of Row Level Security
Next
From: Robert Haas
Date:
Subject: Re: Set visibility map bit after HOT prune