Re: [PATCH] Add session_preload_libraries configuration parameter
От | Dimitri Fontaine |
---|---|
Тема | Re: [PATCH] Add session_preload_libraries configuration parameter |
Дата | |
Msg-id | m27gh1o3ah.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | Re: [PATCH] Add session_preload_libraries configuration parameter (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [PATCH] Add session_preload_libraries configuration
parameter
|
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > local_preload_libraries allows unprivileged users to preload whitelisted > libraries. session_preload_libraries allows superusers to preload any > library. It's hard to see how to consolidate those, at least without > adding another setting that whitelists the libraries somehow, at which > point you haven't really gained anything in terms of complexity. Good point. > I don't know of any actual legitimate uses of local_preload_libraries. > I recall that the plpgsql debugger was meant to use it, but doesn't > anymore. So it's hard to judge what to do about this, without any > actual use cases. Well there's my preprepare thing at https://github.com/dimitri/preprepare I don't think that the whitelisting is actually used in a way to allow for non superusers to load modules in the field, because the only way to do that with local_preload_libraries that I know of is to edit the postgresql.conf file and reload. alter role dim set local_preload_libraries = 'auto_explain'; ERROR: 55P02: parameter "local_preload_libraries" cannot beset after connection start That said, I think we could go with your current patch and revise the local_preload_libraries down the road in the 9.4 development cycle. Having both for a while is a good way to better understand if they are useful to have together. Going to mark your patch ready for commiter, thanks! Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: