Re: exposing pg_controldata and pg_config as functions
От | Michael Paquier |
---|---|
Тема | Re: exposing pg_controldata and pg_config as functions |
Дата | |
Msg-id | CAB7nPqQqxEnP=rXbhL+e+rttkPDJJD4EnRdpFNshP9zVqzDgLw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: exposing pg_controldata and pg_config as functions (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: exposing pg_controldata and pg_config as functions
|
Список | pgsql-hackers |
On Wed, Dec 9, 2015 at 9:18 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Thu, Sep 17, 2015 at 7:12 AM, Andres Freund <andres@anarazel.de> wrote: >> On 2015-08-20 09:59:25 -0400, Andrew Dunstan wrote: >>> Is there any significant interest in either of these? >>> >>> Josh Berkus tells me that he would like pg_controldata information, and I >>> was a bit interested in pg_config information, for this reason: I had a >>> report of someone who had configured using --with-libxml but the xml tests >>> actually returned the results that are expected without xml being >>> configured. The regression tests thus passed, but should not have. It >>> occurred to me that if we had a test like >>> >>> select pg_config('configure') ~ '--with-libxml' as has_xml; >>> >>> in the xml tests then this failure mode would be detected. >> >> On my reading of the thread there seems to be a tentative agreement that >> pg_controldata is useful and still controversy around pg_config. Can we >> split committing this? > > Yeah, the last version of the patch dates of August, and there is > visibly agreement that the information of pg_controldata provided at > SQL level is useful while the data of pg_config is proving to be less > interesting for remote users. Could the patch be rebased and split as > suggested above? I am marking this patch as returned with feedback, there is not much activity... -- Michael
В списке pgsql-hackers по дате отправления: