Identifier downcase change for LATIN1, in v19
Opus 5 found that, under LATIN1, psql running "\d TABLENAME" can find a
different table than the one "SELECT * FROM TABLENAME" reads. Commit 87b2968
"downcase_identifier(): use method table from locale provider" changed this.
While the LLM likes the new backend behavior and argues for making the
frontend match it, I disagree. Identifier downcasing behavior is, in a loose
sense, part of the frontend-backend protocol. I doubt more locale-aware
identifier downcasing could be worth the compatibility break. The backend
should return to v18 identifier downcase behavior.
If new downcase behavior were worthwhile, the change would need to be clearly
release-noted, so other clients with psql-like logic can cope. It would also
entail making psql understand both generations of downcasing behavior, so psql
can do the right downcasing for older server versions it supports.
I'm attaching the LLM's test+report.
Attachments:
87b2968-downcase-test-v0.patchtext/plain; charset=utf-8Download+612-0
On Wed, 2026-08-26 at 15:55 -0700, Noah Misch wrote:
Commit 87b2968
"downcase_identifier(): use method table from locale provider"
changed this.
Thank you for the report. Yes, that was an unintentional behavior
change for provider=builtin, locale=C, single-byte encoding, and a
non-C LC_CTYPE setting.
I think the right fix is to just revert 0a90df58cf & 87b2968df0. Those
were intended to be cleanup to reduce the dependency on the LC_CTYPE
setting, but if we need the dependency for all three providers, then
those commits didn't move us any closer to that goal.
Opus 5 found that, under LATIN1, psql running "\d TABLENAME" can
find a
different table than the one "SELECT * FROM TABLENAME" reads.
To be pedantic, that can happen regardless. There's no guarantee that
the client's libc and the server's libc agree.
Regards,
Jeff Davis