Re: Tightening behaviour for non-immutable behaviour in immutable functions
От | Michael Paquier |
---|---|
Тема | Re: Tightening behaviour for non-immutable behaviour in immutable functions |
Дата | |
Msg-id | YqfzSk6c00yPE6+E@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Tightening behaviour for non-immutable behaviour in immutable functions (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-hackers |
On Mon, Jun 13, 2022 at 06:41:17PM -0700, Peter Geoghegan wrote: > On Mon, Jun 13, 2022 at 1:51 PM Greg Stark <stark@mit.edu> wrote: >> By "relatively common" I think we're talking "nigh universal". Afaics >> there are no warnings in the docs about worrying about search_path on >> IMMUTABLE functions. There is for SECURITY DEFINER but I have to admit >> I wasn't aware myself of all the gotchas described there. > > I didn't realize that it was that bad. Even if it's only 10% as bad as > you say, it would still be very valuable to do something about it > (ideally with an approach that is non-invasive). Having checks implemented so as users cannot bite themselves back is a good idea in the long term, but I have also seen cases where abusing of immutable functions was useful: - Enforce the push down of function expressions to remote server. - Regression tests. Just a few weeks ago I have played with an advisory lock within an index expression. Perhaps I never should have done what the first point was doing anyway, but having a way to disable any of that, be it just a developer option for the purpose of some regression tests, would be nice. Skimming quickly through the patch, any of the checks related to search_path would not apply to the fancy cases I saw, though. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: