Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Mon, Jul 22, 2024 at 10:26 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> I disagree with that. We should put ourselves into the position to
> adopt new Unicode versions without fear. Similar to updates to time
> zones, snowball, etc.
>
> We can't be discussing the merits of the Unicode update every year.
> That would be madness.

Yeah, I agree with that 100%. I can't imagine that we want to, in
effect, develop our own version of Unicode that is not quite the same
as upstream.

We've got to figure out a way to fix this problem from the other end -
coping with updates when they happen. I feel like we've already
discussed the obvious approach at some length: have a way to mark
indexes invalid when "immutable" things change. That doesn't fix
everything because you could, for example, manufacture constraint
violations, even if there are no relevant indexes, so maybe index
invalidation wouldn't be the only thing we'd ever need to do, but it
would help a lot. In view of Jeff's list at the start of the thread,
maybe that mechanism needs to be more general than just
collation-related stuff: maybe there should be a general way to say
"oopsie, this index can't be relied upon until it's rebuit" and a user
could manually do that if they change the definition of an immutable
function. Or there could even be some flag to CREATE FUNCTION that
triggers it for all dependent indexes. I'm not really sure.

If I remember correctly, Thomas Munro put a good deal of work into
developing specifically for collation definition changes a few
releases ago and it was judged not good enough, but that means we just
still have nothing, which is unfortunate considering how often things
go wrong in this area.

--
Robert Haas
EDB: http://www.enterprisedb.com