st 29. 6. 2022 v 8:29 odesÃlatel Tom Lane <t...@sss.pgh.pa.us> napsal:
> Pavel Stehule <pavel.steh...@gmail.com> writes: > > st 29. 6. 2022 v 7:46 odesÃlatel Tom Lane <t...@sss.pgh.pa.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 >
