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 CAB7nPqSWtQ=mdQifowT5Je_tf_akNZw+EM6oMu=z7EVV88_rKQ@mail.gmail.com
Whole thread Raw
In response to Re: exposing pg_controldata and pg_config as functions  (Joe Conway <mail@joeconway.com>)
Responses Re: exposing pg_controldata and pg_config as functions  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
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?
-- 
Michael



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby
Next
From: Pavel Stehule
Date:
Subject: Re: Re: [JDBC] 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102