Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-11-26 19:16:00 -0500, Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > On 2018-11-26 19:04:46 -0500, Joe Conway wrote: > > > > So the correct answer is probably to mark pg_config() stable, but it > > > > still seems to be parallel safe to me. > > > > > > I don't think we should consider immutability to mean anything across > > > major versions. What'd be helped by doing that? We'd have to rule out > > > any behaviour change to any immutable function for that to make > > > sense. Including making an immutable function not immutable anymore. > > > > Then we have to require that all indexes built with immutable functions > > be rebuilt when someone does a pg_upgrade from one major version to the > > next. > > Happened a couple times. The harm from overaggressively removing > immutability, and thus not even being able to add such indexes and > obviously worse query plans, seems much bigger than avoiding the need to > rebuild indexes in some cases.
These two things seem entirely independent in my view, so I'm really not sure that I'm following what you're getting at. We have required specific kinds of indexes to be rebuilt across major version upgrades, yes, but those have almost uniformly been cases where the index was very rarely used or only used in some corner cases. I certainly do not believe we should invalidate all indexes built with immutable functions across major versions upgrades. Perhaps in some cases when we've decided that an immutable function today should work in some different way in a new version then we should complain about or invalidate those indexes, but that's a special case. Taken to an extreme, you could argue that partial indexes should also be rebuilt on major version upgrades, in case we decide that 1 is suddently less than 2, but instead of baking that assumption in, let's just deal with those cases when they come up and write logic into pg_upgrade to detect such usages and make the user aware of them. If you feel that immutability is being overaggressively removed from something, that's fair, but should also be addressed on a case-by-case basis. In this particular case, I don't see any concern that we're going to break user's indexes by changing pg_config() to be stable instead of immutable, and I don't really think we even need to write logic into pg_upgrade for it- unless it could be generalized to detect such cases between versions, in which case I'd be all for that in case we have other such changes. Not sure it's really worth it though, we don't have that happen all that often. Thanks! Stpehen
signature.asc
Description: PGP signature
