Re: Add default role 'pg_access_server_files'
От | Michael Paquier |
---|---|
Тема | Re: Add default role 'pg_access_server_files' |
Дата | |
Msg-id | 20180326071631.GE2759@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Add default role 'pg_access_server_files' (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Add default role 'pg_access_server_files'
|
Список | pgsql-hackers |
On Sun, Mar 25, 2018 at 09:43:25PM -0400, Stephen Frost wrote: > * Michael Paquier (michael@paquier.xyz) wrote: >> On Thu, Mar 08, 2018 at 10:15:11AM +0900, Michael Paquier wrote: >> > Other than that the patch looks in pretty good shape to me. >> >> The regression tests of file_fdw are blowing up because of an error >> string patch 2 changes. > > Fixed in the attached. Thanks for the updated version. This test is fixed. Patch 2 includes the documentation changes from patch 1, which would matter only if you decide to keep things splitted. As far as my brain sees the patch is logically correct. > Note that it'll be a bit more complicated since we can't just remove the > checks from the existing functions- we'll need to have new functions > where the checks are removed and a new extension version that updates to > the new functions and then REVOKE's access to them. Not a big deal, > just pointing out that it's not quite as straight-forward since it's an > extension and we need to deal with environments where the server's been > upgraded and the .so changed, but the existing functions are still in > place with their current public-execute rights. Yeah, that's basically what you did for pgstattuple in fd321a1. I am not sure that I would have time to double-check what you code and the commit fest ends in 5 days. There are many other patches in need of attention, so I would be incline to just do this portion in the future and keep the proposal as-is. My 2c. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: