From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Joe Conway <mail(at)joeconway(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: exposing pg_controldata and pg_config as functions |
Date: | 2015-09-07 23:32:41 |
Message-ID: | 20150907233241.GY2912@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Kouhei Kaigai | 2015-09-07 23:46:20 | Re: One question about security label command |
Previous Message | Andrew Dunstan | 2015-09-07 23:21:07 | Re: exposing pg_controldata and pg_config as functions |