On 02.12.24 23:25, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
>> The behavior is commented (commit 176d5bae1d) in formatting.c:
>
>> * ... When using the default
>> * collation, we apply the traditional Postgres behavior that
>> * forces ASCII-style treatment of I/i, but in non-default
>> * collations you get exactly what the collation says.
>
>> That's a somewhat strange special case (along with similar ones for
>> INITCAP() and UPPER()) that applies to single-byte encodings with the
>> libc provider and the database default collation only. I assume it was
>> done for backwards compatibility?
>
> Well, also for compatibility with our SQL parser's understanding
> of identifier lowercasing.
Maybe that was relevant before the "name" type got its own collation?
>> Should I put the special case back?
>
> I think so. It's stood for a lot of years now without field
> complaints, and I'm fairly sure there *were* field complaints
> before. (I think that behavior long predates 176d5bae1d, which
> was just restoring the status quo ante after somebody else's
> overenthusiastic application of system locale infrastructure.)
I've been tempted several times recently to suggest that we should
remove the separate libc-with-single-byte-encoding-but-not-C-locale code
paths, because they have zero test coverage and probably about zero
users. But if those code paths actually have different semantics in
some cases, then that will be difficult. Just something to keep in mind.
