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

From Alvaro Herrera
Subject Re: exposing pg_controldata and pg_config as functions
Date
Msg-id 20150907233241.GY2912@alvherre.pgsql
Whole thread Raw
In response to Re: exposing pg_controldata and pg_config as functions  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: exposing pg_controldata and pg_config as functions  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Andrew Dunstan wrote:

> 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.

I think that use case would be better served by a completely different
interface -- some way to query the server, "does this installation
support feature X?"  What you proposed, using a regexp to look for
--enable-xml in the pg_config --configure output, doesn't look all that
nice to me.

For instance, we already have sql_features.txt, which is exposed as a
table in the docs.  It's not quite the same thing (because what you want
is not the same as conformance to the SQL standard), but I think a
system view that has a list of features and a boolean flag for each one
is more practical (though admittedly it's more work to implement.)
Another alternative which I think is simpler is a read-only GUC, which
we already have for a number of compile-time properties.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Atsushi Yoshida
Date:
Subject: Re: Too many duplicated condition query return wrong value
Next
From: Kouhei Kaigai
Date:
Subject: Re: One question about security label command