Date: Tue, 12 Dec 2023 11:52:46 +0100
From: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Sorting regression of text function result since commit
 586b98fdf1aae
Message-ID: <20231212115246.376da94b@karst>
In-Reply-To: <2311662.1702327392@sss.pgh.pa.us>
References: <20231211210951.5020a5d6@karst>
	<2311662.1702327392@sss.pgh.pa.us>
Organization: Dalibo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/20231212115246.376da94b%40karst>
Precedence: bulk

On Mon, 11 Dec 2023 15:43:12 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Jehan-Guillaume de Rorthais <jgdr@dalibo.com> writes:
> > It looks like since 586b98fdf1aae, the result type collation of
> > "convert_from" is forced to "C", like the patch does for type "name",
> > instead of the "default" collation for type "text". =20
>=20
> Well, convert_from() inherits its result collation from the input,
> per the normal rules for collation assignment [1].
>=20
> > Looking at hints in the header comment of function "exprCollation", I p=
oked
> > around and found that the result collation wrongly follow the input
> > collation in this case. =20
>=20
> It's not "wrong", it's what the SQL standard requires.

Mh, OK. This is at least a surprising behavior. Having a non-data related
argument impacting the result collation seems counter-intuitive. But I
understand this is by standard, no need to discuss it.

> > I couldn't find anything explaining this behavior in the changelog. It =
looks
> > like a regression to me, but if this is actually expected, maybe this
> > deserve some documentation patch? =20
>=20
> The v12 release notes do say
>=20
>     Type name now behaves much like a domain over type text that has
>     default collation =E2=80=9CC=E2=80=9D.

Sure, and I saw it, but reading at this entry, I couldn't guess this could =
have
such implication on text result from a function call. That's why I hunt for
the precise commit and was surprise to find this was the actual change.

> You'd have similar results from an expression involving such a domain,
> I believe.
>=20
> I'm less than excited about patching the v12 release notes four
> years later.  Maybe, if this point had come up in a more timely
> fashion, we'd have mentioned it --- but it's hardly possible to
> cover every potential implication of such a change in the
> release notes.

This could have been documented in the collation concept page, as a trap to=
 be
aware of. A link from the release note to such a small paragraph would have
been enough to warn devs this might have implications when mixed with other
collatable types. But I understand we can not document all the traps paving=
 the
way to the standard anyway.

Thank you for your explanation!

Regards,