Re: Feature Request: pg_replication_master()

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Feature Request: pg_replication_master()
Дата
Msg-id CA+TgmoYe=+uACJufWUuhEA+qDafM09Q+-yo=0ZzFCiQdStARNg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Feature Request: pg_replication_master()  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Feature Request: pg_replication_master()
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Review of Row Level Security
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Set visibility map bit after HOT prune