Greetings,
* Andres Freund (andres@anarazel.de) wrote:
> On 2018-11-26 19:34:03 -0500, Stephen Frost wrote:
> > These two things seem entirely independent in my view, so I'm really not
> > sure that I'm following what you're getting at.
>
> All I said is that I don't think it's a reasonable policy to mark all
> functions that potentially could change across major versions as
> immutable. I've no problem with changing pg_config in particular,
> especially as it - as has been pointed - clearly can change in minor
> versions / recompiles.
I'm... not following.
If a function's results can change across minor or major versions, we
shouldn't be marking it as immutable because, by definition, it's not
immutable.
We, today, have a baked in assumption that any function marked as
immutable will remain immutable across all major versions that we allow
indexes to be retained through, which is all of them since about 8.3 at
this point.
We absolutely need a policy that if you decide to change the results of
some immutable function across a major version change, you need to
consider the results on indexes and possibly write into pg_upgrade
checks to try and detect any usage of that immutable function. I hope
we're in agreement there.
In other words, maybe it isn't a sealed-in-concrete policy that you
can't go around changing what an immutable function returns, but you
certainly better have a really good justification for it, and write
all of the code to detect any cases where that could cause incorrect
results from the database, including pg_upgrade throwing a big error if
it finds any indexes (or maybe even functions...) using it, and even
then I'm pretty darn skeptical about accepting it.
Thanks!
Stephen