From: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sorting regression of text function result since commit 586b98fdf1aae |
Date: | 2023-12-12 10:52:46 |
Message-ID: | 20231212115246.376da94b@karst |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 11 Dec 2023 15:43:12 -0500
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)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".
>
> Well, convert_from() inherits its result collation from the input,
> per the normal rules for collation assignment [1].
>
> > Looking at hints in the header comment of function "exprCollation", I poked
> > around and found that the result collation wrongly follow the input
> > collation in this case.
>
> 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?
>
> The v12 release notes do say
>
> Type name now behaves much like a domain over type text that has
> default collation āCā.
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.
>
> 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,
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2023-12-12 11:25:23 | Re: brininsert optimization opportunity |
Previous Message | Michael Paquier | 2023-12-12 10:44:57 | Re: Adding facility for injection points (or probe points?) for more advanced tests |