public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Noah Misch <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Daniel Verite <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Jeremy Schneider <[email protected]>
Cc: [email protected]
Subject: Re: Built-in CTYPE provider
Date: Sat, 06 Jul 2024 16:19:21 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Noah Misch <[email protected]> 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

view thread (13+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Built-in CTYPE provider
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox