Re: Feature Request: pg_replication_master()
От | Bruce Momjian |
---|---|
Тема | Re: Feature Request: pg_replication_master() |
Дата | |
Msg-id | 20121220191546.GL20015@momjian.us обсуждение исходный текст |
Ответ на | Re: Feature Request: pg_replication_master() (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wed, Dec 19, 2012 at 07:32:33PM -0500, Robert Haas wrote: > 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. 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: