Re: Built-in CTYPE provider

Noah Misch <noah(at)leadboat(dot)com> writes:
> As a released feature, NORMALIZE() has a different set of remedies to choose
> from, and I'm not proposing one. I may have sidetracked this thread by
> talking about remedies without an agreement that pg_c_utf8 has a problem. My
> question for the PostgreSQL maintainers is this:

> textregexeq(... COLLATE pg_c_utf8, '[[:alpha:]]') and lower(), despite being
> IMMUTABLE, will change behavior in some major releases. pg_upgrade does not
> have a concept of IMMUTABLE functions changing, so index scans will return
> wrong query results after upgrade. Is it okay for v17 to release a
> pg_c_utf8 planned to behave that way when upgrading v17 to v18+?

I do not think it is realistic to define "IMMUTABLE" as meaning that
the function will never change behavior until the heat death of the
universe. As a counterexample, we've not worried about applying
bug fixes or algorithm improvements that change the behavior of
"immutable" numeric computations. It might be unwise to do that
in a minor release, but we certainly do it in major releases.

I'd say a realistic policy is "immutable means we don't intend to
change it within a major release". If we do change the behavior,
either as a bug fix or a major-release improvement, that should
be release-noted so that people know they have to rebuild dependent
indexes and matviews.

It gets stickier for behaviors that aren't fully under our control,
which is the case for a lot of locale-related things. We cannot then
promise "no changes within major releases". But I do not think it
is helpful to react to that fact by refusing to label such things
immutable. Then we'd just need another mutability classification,
and it would effectively act the same as immutable does now, because
people will certainly wish to use these functions in indexes etc.

regards, tom lane