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

From Michael Paquier
Subject Re: exposing pg_controldata and pg_config as functions
Date
Msg-id CAB7nPqQZsWtXJTO=KH15PHVexeDd7cKYkhgc8Le4vsnKGS6Odw@mail.gmail.com
Whole thread Raw
In response to Re: exposing pg_controldata and pg_config as functions  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: exposing pg_controldata and pg_config as functions  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
On Tue, Jan 19, 2016 at 1:49 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Jan 19, 2016 at 11:08 AM, Joe Conway <mail@joeconway.com> wrote:
>> On 01/18/2016 04:16 PM, Joe Conway wrote:
>>> Please see the attached. Duplication removed.
>>
>> Actually please see this version instead.
>
> Thanks for the new patch.
>
> +               tuplestore_puttuple(tupstore, tuple);
> +       }
> +
> +       /*
> +        * no longer need the tuple descriptor reference created by
> The patch has some whitespaces.
>
> +REVOKE ALL on pg_config FROM PUBLIC;
> +REVOKE EXECUTE ON FUNCTION pg_config() FROM PUBLIC;
> I guess that this portion is still under debate :)
>
> make[1]: Nothing to be done for `all'.
> make -C ../backend submake-errcodes
> make[2]: *** No rule to make target `config_info.o', needed by
> `libpgcommon.a'.  Stop.
> make[2]: *** Waiting for unfinished jobs....
> The patch is visibly forgetting to include config_info.c, which should
> be part of src/common.
>
>  /*
> + * This function cleans up the paths for use with either cmd.exe or Msys
> + * on Windows. We need them to use filenames without spaces, for which a
> + * short filename is the safest equivalent, eg:
> + *             C:/Progra~1/
> + */
> +void
> +cleanup_path(char *path)
> +{
> Perhaps this refactoring would be useful as a separate patch?

You need as well to update @pgcommonallfiles in Mkvcbuild.pm or the
compilation with MSVC is going to fail.
-- 
Michael



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Re: [JDBC] 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102
Next
From: Vitaly Burovoy
Date:
Subject: Re: custom function for converting human readable sizes to bytes