Re: [18] Unintentional behavior change in commit e9931bfb75
От | Tom Lane |
---|---|
Тема | Re: [18] Unintentional behavior change in commit e9931bfb75 |
Дата | |
Msg-id | 1687051.1733178349@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [18] Unintentional behavior change in commit e9931bfb75 (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: [18] Unintentional behavior change in commit e9931bfb75
Re: [18] Unintentional behavior change in commit e9931bfb75 |
Список | 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
В списке pgsql-hackers по дате отправления: