Re: Tightening behaviour for non-immutable behaviour in immutable functions

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(at)mit(dot)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