Re: [18] Unintentional behavior change in commit e9931bfb75
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
Cc: pgsql-hackers@postgresql.org
Date: 2024-12-02T22:25:49Z
Lists: pgsql-hackers
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
Commits
-
Another unintentional behavior change in commit e9931bfb75.
- 2e5353be2534 18.0 landed
-
Improve comment in regc_pg_locale.c.
- b107744ce737 18.0 landed
-
Fix unintentional behavior change in commit e9931bfb75.
- e3fa2b037c6f 18.0 landed
-
Remove support for null pg_locale_t most places.
- e9931bfb7515 18.0 cited
-
Fix up handling of C/POSIX collations.
- 176d5bae1d63 9.1.0 cited