Re: exposing pg_controldata and pg_config as functions

On 01/16/2016 06:02 AM, Michael Paquier wrote:
> On Wed, Dec 30, 2015 at 9:08 AM, Joe Conway <mail(at)joeconway(dot)com> wrote:
>> 3) Adds new functions, more or less in line with previous discussions:
>> * pg_checkpoint_state()
>> * pg_controldata_state()
>> * pg_recovery_state()
>> * pg_init_state()
>
> Taking the opposite direction of Josh upthread, why is this split
> actually necessary? Isn't the idea to provide a SQL interface of what
> pg_controldata shows? If this split proves to be useful, shouldn't we
> do it as well for pg_controldata?

The last discussion moved strongly in the direction of separate
functions, and that being different from pg_controldata was not a bad
thing. That said, I'm still of the opinion that there are legitimate
reasons to want the command line pg_controldata and the SQL functions to
produce equivalent, if not identical, results. I just wish we could get
a clear consensus one way or the other.

>> ===============
>> Missing (TODO once agreement on the above is reached):
>> ---------------
>> a) documentation
>
> This would be good to have.

Sure, once we have settled on a direction.

>> b) catversion bump
>
> That's committer work.

I know, but since I will be the committer if this thing ever gets that
far, I wanted to point out that I had not forgotten that little detail ;-)

>> c) regression tests
>
> Hm, what would be the value of those tests? I think we could live
> without for simple functions like that honestly.

Works for me.

> I think that those functions should be superuser-only. They provide
> information about the system globally.

The tail of this thread seems to be headed away from this direction.
I'll take another look and propose something concrete.

Thanks for the comments!

Joe

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