Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Certainly, if we make a change that we know is likely to require people to > reindex affected indexes, that should be documented in the release notes. > But I think it's pointless to imagine that we can achieve perfection in > identifying trouble cases, or even to spend significantly more resources > than we do now on trying. I've not seen many field trouble reports that > seem to trace back to such issues.
Just to be clear- I think the way we've been operating is striking a good balance and that's because people do think about these things and consider what can happen in indexes when we make changes to immutable functions. This thread feels like there's people arguing we should reduce our level of effort there to a point where we don't care about on-disk representation in indexes across major versions when immutable functions are involved and I strongly disagree with that. > Maybe the tl;dr version of that is that the immutable/stable/volatile > division is too simplistic and we need to refine it. But I don't > know what a better design would look like. Also, I suspect that real > users are already hard put to it to label their functions correctly > in the three-way regime. Making it more complicated might make things > actively worse, if it increases the odds of functions being mislabeled. I haven't got any great ideas about what a better design would look like either. Just brainstorming, but perhaps having a flag that basically says "this can be used in indexes" might be useful as a way to filter out any immutable functions that shouldn't be used in indexes? I'm not sure that we've actually got any of those and I wouldn't want to arbitrairly limit what users can do without there being a good reason either. Maybe such a flag would make people (users and hackers alike) think a bit more about making changes and if they need to rebuild indexes or such? Might also just get in the way though. Thanks! Stephen
signature.asc
Description: PGP signature