Re: pg_primary_conninfo
От | Magnus Hagander |
---|---|
Тема | Re: pg_primary_conninfo |
Дата | |
Msg-id | AANLkTi=EjWUfoNQtb+vWL5EyrgfJRPyGKo8ZYMC__Z6M@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_primary_conninfo (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pg_primary_conninfo
Re: pg_primary_conninfo |
Список | pgsql-hackers |
On Tue, Dec 28, 2010 at 18:12, Robert Haas <robertmhaas@gmail.com> wrote: > On Dec 28, 2010, at 10:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I'm still wondering what's the actual use-case for exposing this inside >> SQL. Those with a legitimate need-to-know can look at the slave >> server's config files, no? > > SQL access is frequently more convenient, though. Yes. Reading it in the files does not scale with $LOTS of servers, be them slaves or masters or both. You can't assume that people have direct filesystem access to the server (or at least it's data directory) - particularly when the organisation is large enough that you have different teams running the db's and the OS's, not to mention when you have some on-call group who verifies the things in the middle of the night... Unless you mean reading them with pg_read_file() and then parsing it manually, but that just requires everybody to re-invent the wheel we already have in the parser. > Although maybe now that we've made recovery.conf use the GUC lexer we oughta continue in that vein and expose those parametersas PGC_INTERNAL GUCs rather than inventing a new function for it... That's definitely another option that I wouldn't object to if people prefer that way. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: