Re: User's responsibility when using a chain of "immutable" functions?

st 29. 6. 2022 v 8:29 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > st 29. 6. 2022 v 7:46 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
> >> ... that result has discouraged most people from spending much
> >> time on mechanically checking such things. If you declare a function
> >> immutable, Postgres will believe you; the consequences if you lied
> >> are on your own head.
>
> > We cannot ensure that the function is immutable, but we can detect that
> the
> > function is not very probably immutable (in execution time).
>
> Sure, there are a lot of easy cases where we could say "that's
> obviously not immutable". But is it worth spending engineering
> effort and runtime on that? I suspect the cases that people
> might actually mess up are less obvious, so that we might
> accomplish little more than offering a false sense of security.
>

This is a hard question. I know so many hard performance issues are related
to missing STABLE or IMMUTABLE flags of some functions.

On second hand I am relatively happy with the current state and in warnings
implemented in plpgsql_check. Unfortunately, only few users know so
plpgsql_check exists.

I understand that implementation of this extra check can be very expensive.
It can require handling exceptions everywhere, because you need to hold
caller context everywhere. And it can have zero benefit, when all
customer's functions have the default volatile flag. I have no idea how to
implement it better, without significant performance impact.

Regards

Pavel

> regards, tom lane
>