>> 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).
I would vote for making host:port part visible to non-superusers. This info is definitely usable in combination with pg_current_xlog_location() and pg_last_xlog_receive_location() to allow non-superusers to monitor streaming replication.
Given that primary_conninfo is already parsed by libpq, how difficult would it be to extract and store/display those host:port components.
