Re: exposing pg_controldata and pg_config as functions - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: exposing pg_controldata and pg_config as functions
Date
Msg-id 20150826133308.GF3685@tamriel.snowman.net
Whole thread Raw
In response to Re: exposing pg_controldata and pg_config as functions  (Joe Conway <mail@joeconway.com>)
Responses Re: exposing pg_controldata and pg_config as functions  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
* Joe Conway (mail@joeconway.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

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: multiple psql option -c
Next
From: Alexander Korotkov
Date:
Subject: Re: WIP: Rework access method interface