On Mon, 2024-07-22 at 11:14 -0400, Robert Haas wrote:
> On Mon, Jul 22, 2024 at 10:26 AM Peter Eisentraut
> <peter@eisentraut.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%.
It's hard for me to argue; that was my reasoning during development.
But Noah seems to have a very strong opinion on this matter:
https://www.postgresql.org/message-id/20240629220857.fb.nmisch%40google.com
and I thought this thread would be a better opportunity for him to
express it. Noah?
> 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"
...
> 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,
Yeah, see ec48314708. The revert appears to be for a number of
technical reasons, but even if we solve all of those, it's hard to have
a perfect solution that accounts for plpgsql functions that create
arbitrary query strings and EXECUTE them.
Though perhaps not impossible if we use some kind of runtime detection.
We could have some kind of global context that tracks, at runtime, when
an expression is executing for the purposes of an index. If a function
depends on a versioned collation, then mark the index or add a version
somewhere.
Regards,
Jeff Davis