Greetings,
* Tom Lane (tgl@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