| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Joshua Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net> |
| Subject: | Re: Feature Request: pg_replication_master() |
| Date: | 2012-12-20 00:32:33 |
| Message-ID: | CA+TgmoYe=+uACJufWUuhEA+qDafM09Q+-yo=0ZzFCiQdStARNg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 19, 2012 at 5:34 PM, Simon Riggs <simon(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-12-20 00:42:25 | Re: Set visibility map bit after HOT prune |
| Previous Message | Robert Haas | 2012-12-20 00:27:59 | Re: Review of Row Level Security |