On Sun, Aug 23, 2015 at 7:50 AM, Joe Conway <m...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
