Re: exposing pg_controldata and pg_config as functions

* Joe Conway (mail(at)joeconway(dot)com) wrote:
> Issues needing comment:
> a.) Which items need hiding from non-superusers and should the value be
> redacted or the entire result set row be suppressed?

I'm of the opinion that we need to at least redact it and that what we
should do is simply suppress the entire result set until we provide a
way for administrators to manage who can access it (eg: default roles,
this one would fall under 'pg_monitor', imo).

> b.) There is a difference in the formatting of timestamps between the
> pg_controldata binary and the builtin function. To see it do:
>
> diff -c <(pg_controldata) \
> <(psql -qAt -c "select rpad(name || ':', 38) || setting
> from pg_controldata")
>
> What I see is:
>
> pg_controldata
> ! pg_control last modified: Tue 25 Aug 2015 08:10:42 PM PDT
> pg_controldata()
> ! pg_control last modified: Tue Aug 25 20:10:42 2015
>
> Does it matter?

I don't think we can help that, can we? At the least, the
pg_controldata() output should match what the GUCs and whatnot tell us
to do, but the pg_controldata file needs to include things like the
timezone. In the end, I don't believe we need to make them match and
trying to would just make things ugly.

> c.) There is some common code between pg_controldata.c in bin and
> pg_controldata.c in backend/utils/misc. Specifically the string
> definitions in printf statements match those in ControlData[], and
> dbState() and wal_level_str() are in both places. Any opinions
> on consolidating them in src/common somewhere?

Haven't got any great ideas about exactly how to consolidate them, but I
do think it'd be good to do so..

Thanks!

Stephen