Le 28/12/2010 19:30, Tom Lane a écrit : > Gurjeet Singh <singh.gurj...@gmail.com> writes: >> On Tue, Dec 28, 2010 at 12:12 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> SQL access is frequently more convenient, though. 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... > >> +1 for SQL access, but exposing it via pg_settings opens up the security >> problem as there might be sensitive info in those GUCs. > > IIRC we do have a GUC property that hides the value from non-superusers, > so we could easily have a GUC that is equivalent to the proposed > pg_primary_conninfo function. Of course this does nothing for my > objections to the function. Also, I'm not sure how we'd deal with the > state-dependency aspect of it (ie, value changes once you exit recovery > mode). >
We already have superuser GUC. b1=> show data_directory; ERROR: must be superuser to examine "data_directory" We only need to do the same for primary_conninfo and trigger_file (as I remember it, there are the only ones needing this). -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
