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

From Joe Conway
Subject Re: exposing pg_controldata and pg_config as functions
Date
Msg-id 55EC9544.2030209@joeconway.com
Whole thread Raw
In response to Re: exposing pg_controldata and pg_config as functions  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: exposing pg_controldata and pg_config as functions  (Peter Eisentraut <peter_e@gmx.net>)
Re: exposing pg_controldata and pg_config as functions  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.

Given that, my own feeling is that if we provide a SQL interface at all,
it ought to be pretty much the exact same output as the command line
programs produce.

To the extent that we want specific pg_controldata output in non-text
form, we should identify which items those are and provide individual
functions for them.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development


pgsql-hackers by date:

Previous
From: Victor Wagner
Date:
Subject: Discussion summary: Proposal: Implement failover on libpq connect level.
Next
From: Ildus Kurbangaliev
Date:
Subject: Re: [PATCH] Refactoring of LWLock tranches