Re: Tightening behaviour for non-immutable behaviour in immutable functions - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Tightening behaviour for non-immutable behaviour in immutable functions
Date
Msg-id YqfzSk6c00yPE6+E@paquier.xyz
Whole thread Raw
In response to Re: Tightening behaviour for non-immutable behaviour in immutable functions  (Peter Geoghegan <pg@bowt.ie>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "buffer too small" or "path too long"?
Next
From: Tom Lane
Date:
Subject: Re: "buffer too small" or "path too long"?