Re: exposing pg_controldata and pg_config as functions

On 09/06/2015 11:17 PM, Peter Eisentraut wrote:
> On 9/6/15 3:34 PM, Joe Conway 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
> But then they also have no use for the information that pg_config prints
> out.
>
>> 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.
> That argument makes no sense to me.
>
> Again, we need to think about what actual use there is for this
> information.  Just because the information exists somewhere, but you
> can't access it, doesn't mean we just need to copy it around.


I already gave a use case that you dismissed in favour of a vague 
solution that we don't actually have. You seem to be the only person 
objecting to this proposal.

cheers

andrew