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

st 29. 6. 2022 v 7:46 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 6:28 odesílatel Bryn Llewellyn <bryn(at)yugabyte(dot)com>
> napsal:
> >> Moreover, this "hermetic" property of a to-be-immutable function can be
> >> established only by human analysis of the function's source code.
>
> > Our immutable functions are more tolerant than they should be - for real
> > immutable functions we should disallow SQL inside functions (and
> everything
> > that is not immutable (plpgsql_check raises warning in this case)), but
> it
> > is allowed.
>
> It's generally believed that Turing's proof of the undecidability of
> the halting problem [1] implies that it's impossible to mechanically
> prove or refute function properties like immutability. Admittedly,
> Turing was concerned with the most general case --- that is, he showed
> that *there exist* cases for which no algorithm can give the right
> answer, not that any specific practical case can't be proven.
> Still, 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).

calling volatile function from immutable function
using SELECT from tables inside immutable function

This is a clear violation of some "protocol". I know why it is, and I don't
propose change, because it can break thousands of applications. And for
some specific cases the strong restrictivity can be safe but not practical.

> regards, tom lane
>
> [1] https://en.wikipedia.org/wiki/Halting_problem
>