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.
> 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.)
regards, tom lane
