On Tue, Dec 28, 2010 at 18:12, Robert Haas <robertmh...@gmail.com> wrote: > On Dec 28, 2010, at 10:34 AM, Tom Lane <t...@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 parameters as 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
