Re: exposing pg_controldata and pg_config as functions

On Sun, Aug 23, 2015 at 7:50 AM, Joe Conway <mail@joeconway.com> wrote:
> 1) The syntax is a bit different than what Andrew proposed:
>
> 8<----------------
> select setting ~ '--with-libxml' as has_xml
> from pg_config
> where name = 'CONFIGURE';
>  has_xml
> - ---------
>  t
> (1 row)
> 8<----------------
>
> In particular note that the name values are all upper case to be
> consistent with pg_config, and at least currently there is no version
> of the function which accepts a name as an argument (didn't seem
> worthwhile to me).

Compatibility by default with the binary pg_config makes sense, users
could just wrap an SQL with lower() or upper() if needed.

> 2) No docs or related regression test yet. I will do that if there is
> enough interest in this getting committed. So far no one except Andrew
> and I have chimed in.

I think that's a good thing to have, now I have concerns about making
this data readable for non-superusers. Cloud deployments of Postgres
are logically going to block the access of this view.

> 4) The static function cleanup_path() was borrowed from
>
>     src/bin/pg_config/pg_config.c

cleanup_path is perhaps a candidate for src/port/path.c?

>
> It is a small and stable function (no change since 2010 AFAICS), so
> maybe not worth the effort, but I was wondering if it should be moved
> to src/common somewhere and shared.
>
> I will add this to the next commitfest. Comments/feedback encouraged.

+ Datum pg_config(PG_FUNCTION_ARGS);
+
+ PG_FUNCTION_INFO_V1(pg_config);

The declaration of the function is not needed, PG_FUNCTION_INFO_V1
takes care of it.
Regards,
-- 
Michael