Re: exposing pg_controldata and pg_config as functions

On Sun, Sep 6, 2015 at 3:34 PM, Joe Conway <mail(at)joeconway(dot)com> wrote:
> On 09/02/2015 02:54 PM, Alvaro Herrera wrote:
>> Josh Berkus wrote:
>>> On 09/02/2015 02:34 PM, Alvaro Herrera wrote:
>>>> I think trying to duplicate the exact strings isn't too nice an
>>>> interface.
>>>
>>> Well, for pg_controldata, no, but what else would you do for pg_config?
>>
>> I was primarily looking at pg_controldata, so we agree there.
>>
>> As for pg_config, I'm confused about its usefulness -- which of these
>> lines are useful in the SQL interface? Anyway, I don't see anything
>> better than a couple of text columns for this case.
>
> There are production environments where even the superuser has no
> direct, local, command line access on production database servers (short
> of intentional hacking, which would be frowned upon at best), and the
> only interface for getting information from postgres is via a database
> connection. So to the extent pg_config and pg_controldata command line
> binaries are useful, so is the ability to get the same output via SQL.

I don't buy that argument as far as pg_config is concerned. That's
mostly providing local pathnames. If you don't have command-line
access to the box where the server is running, you not only can't use
that information, but you probably aren't really entitled to it.

I see exposing the pg_controldata information as reasonable because
that's actually facts about the database cluster, rather than the
system on which it is running.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company