Message-ID: <818d9d27f53cb63db2dac036b3ce988603c79cf5.camel@j-davis.com>
Subject: Re: Order changes in PG16 since ICU introduction
From: Jeff Davis <pgsql@j-davis.com>
To: "Jonathan S. Katz" <jkatz@postgresql.org>, Robert Haas
	 <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Regina Obe <lr@pcorp.us>, Peter Eisentraut
	 <peter.eisentraut@enterprisedb.com>, Sandro Santilli <strk@kbt.io>, 
	pgsql-hackers@lists.postgresql.org
Date: Thu, 18 May 2023 11:26:14 -0700
In-Reply-To: <7f18878d-f3e2-1e81-4456-1198937242bd@postgresql.org>
References: <000b01d97465$c34bbd60$49e33820$@pcorp.us>
	 <533d93c5-f604-8e5f-4a48-975c08c53d59@enterprisedb.com>
	 <3365333.1682098091@sss.pgh.pa.us>
	 <002d01d97477$f0395640$d0ac02c0$@pcorp.us>
	 <3367226.1682099185@sss.pgh.pa.us>
	 <003b01d9747a$910471c0$b30d5540$@pcorp.us>
	 <3368986.1682099982@sss.pgh.pa.us>
	 <000001d9747d$066b7560$13426020$@pcorp.us>
	 <3372735.1682101425@sss.pgh.pa.us>
	 <f83f089ee1e9acd5dbbbf3353294d24e1f196e95.camel@j-davis.com>
	 <CA+TgmobxgvonJT8vO_v0k9_rgDmn0CKvTe48Z=w95rrBqC95KA@mail.gmail.com>
	 <7ee07b7d5aa4fb0b47e5657640568fdd25ba168f.camel@j-davis.com>
	 <CA+TgmoaPGx+R6mOcYQwDfqGoZxd=SncDCDt9mYjz5AD5tFd8sw@mail.gmail.com>
	 <2ffe8ffb9291b9390b9ed6c1e34b4fae8e8ce324.camel@j-davis.com>
	 <25787ec7-4c04-9a8a-d241-4dc9be0b1ba3@postgresql.org>
	 <605324592391599a7ecd522087edbd00720793b7.camel@j-davis.com>
	 <f353900f4c5777b02e9c7ef85326f1954ffeccea.camel@j-davis.com>
	 <52553877-7966-e25f-6c74-a974a504250e@postgresql.org>
	 <a28aba5fa6bf1abfff96e40b6d6acff8412edb15.camel@j-davis.com>
	 <7f18878d-f3e2-1e81-4456-1198937242bd@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu1 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/818d9d27f53cb63db2dac036b3ce988603c79cf5.camel%40j-davis.com>
Precedence: bulk

On Thu, 2023-05-18 at 13:58 -0400, Jonathan S. Katz wrote:
> =C2=A0From my read of them, as an app developer I'd be very unlikely to
> use=20
> this. Maybe there is something with building out some collation rules
> vis-a-vis an extension, but I have trouble imagining the use-case. I
> may=20
> also not be the target audience for this feature.

That's a problem for the ICU rules feature. I understand some features
may be for domain experts only, but we at least need to call that out
so that ordinary developers don't get confused. And we should hear from
some of those domain experts that they actually want it and it solves a
real problem.

For the features that can be described with collation
settings/attributes right in the locale name, the use cases are more
plausible and we've supported them since v10, so it's good to document
them as best we can. It's hard to expose only the particular ICU
collation settings we understand best (e.g. the "ks" setting that
allows case insensitive collation), so it's inevitable that there will
be some settings that are more obscure and harder to document.

But in the case of ICU rules, they are newly-supported in 16, so there
should be a clear reason we're adding them. Otherwise we're just
setting up users for confusion or problems, and creating backwards-
compatibility headaches for ourselves (and the last thing we want is to
fret over backwards compatibility for a feature with no users).

Beyond that, there seems to be some danger: if the syntax for rules is
not perfectly compatible between ICU versions, the user might run into
big problems.

Regards,
	Jeff Davis