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

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org, Daniel Verite <daniel(at)manitou-mail(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeremy Schneider <schneider(at)ardentperf(dot)com>
Subject: Re: [18] Policy on IMMUTABLE functions and Unicode updates
Date: 2024-07-22 16:34:42
Message-ID: 0d6b2af984710fa8825f846ece416e6240273fd8.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2024-07-22 at 11:14 -0400, Robert Haas wrote:
> 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%.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-07-22 16:46:01 Re: xid_wraparound tests intermittent failure.
Previous Message Justin Pryzby 2024-07-22 16:28:23 Re: warn if GUC set to an invalid shared library