Greetings, * Andres Freund (and...@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
signature.asc
Description: PGP signature
