Re: pgsql: Move tablespace path re-creation from the makefiles to pg_regres
От | Michael Paquier |
---|---|
Тема | Re: pgsql: Move tablespace path re-creation from the makefiles to pg_regres |
Дата | |
Msg-id | YG/tf6HTZFj4hWlb@paquier.xyz обсуждение исходный текст |
Ответ на | Re: pgsql: Move tablespace path re-creation from the makefiles to pg_regres (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: pgsql: Move tablespace path re-creation from the makefiles to pg_regres
|
Список | pgsql-hackers |
On Wed, Mar 24, 2021 at 07:56:59PM -0700, Noah Misch wrote: > That would entail forbidding various shell metacharacters in @testtablespace@. > One could avoid imposing such a restriction by adding a mkdir() function to > regress.c and writing it like: > > CREATE FUNCTION mkdir(text) > RETURNS void AS '@libdir@/regress@DLSUFFIX@', 'regress_mkdir' > LANGUAGE C STRICT\; > REVOKE ALL ON FUNCTION mkdir FROM public; > SELECT mkdir('@testtablespace@'); > CREATE TABLESPACE regress_tblspace LOCATION '@testtablespace@'; Sounds simple. >> I doubt that all the Windows environments would be able to get their >> hands on that. > >> And I am not sure either that this would work when it >> comes to the CI case, again on Windows. > > How might a CI provider break that? I am wondering about potential issues when it comes to create the base tablespace path from the Postgres backend, while HEAD does it while relying on a restricted token obtained when starting pg_regress. I have compiled a simple patch that uses a SQL function for the base tablespace directory creation, that I have tested on Linux and MSVC. To get some coverage with the CF bot, I am adding a CF entry with this thread. I am still not sure if people would prefer this approach over what's on HEAD. So if there are any opinions, please feel free. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: