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 по дате отправления: