Bryn Llewellyn <bryn@yugabyte.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> No. You marked the functions as "immutable", and then you broke that
>> promise by changing what they'd need to output.
> Thank you for the very quick response. This is what the Version 12 doc says on “immutable”:
>> An IMMUTABLE function cannot modify the database and is guaranteed to return the same results given the same
argumentsforever.
Indeed. f1() has no arguments, therefore an immutable marking is a
promise --- made by you to the database, NOT vice versa --- that its
output will never change at all. (f2 likewise, although in this
particular example that's not what matters.) Optimizations made on
the strength of such a promise are not bugs.
As a general rule, immutable functions that inspect the database's
contents are probably wrongly marked. We don't forbid such coding,
because there are narrow use-cases for it, but I tend to believe
that it's a red flag for misdesign.
> I couldn’t find an “all bets are off” caveat for the case where
> either an “immutable” function itself or any of its dependency
> parents is recompiled.
We do not attempt to document what might go wrong when you lie
about the volatility classification of a function. There are
a lot of possibilities, many of them worse than what you have
here, and there's no reason to think that the implications will
be stable enough to be worth documenting.
> I had read “forever” to mean “forever until the function, or any of
> its dependency parents, is semantically changed”.
That's a curious reading of "forever".
> And this is the caveated meaning that Oracle database implements for
> its moral equivalent “deterministic”.
Nowhere do we claim to do exactly what Oracle does, especially when
it's not even the same syntax. "immutable" is NOT the same thing
as "deterministic".
regards, tom lane
