Re: BUG #7913: TO_CHAR Function & Turkish collate

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #7913: TO_CHAR Function & Turkish collate
Дата
Msg-id 16008.1362325379@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #7913: TO_CHAR Function & Turkish collate  (a_dursun@hotmail.com)
Ответы Re: BUG #7913: TO_CHAR Function & Turkish collate  (Peter Eisentraut <peter_e@gmx.net>)
Re: BUG #7913: TO_CHAR Function & Turkish collate  (Euler Taveira <euler@timbira.com>)
Список pgsql-bugs
a_dursun@hotmail.com writes:
> prod=# SELECT TO_CHAR('2013-03-01'::date,'DAY');
>  to_char
> ----------
>  FRÄ°DAY
> (1 row)
> But it must return as FRIDAY.
> Our database lc_collate is tr_TR.UTF-8 and encoding is UTF8.

It looks like the cause of this is that the result is computed as
str_toupper("Friday"), and str_toupper() applies a collation-sensitive
upcasing rule.

I think the use of str_toupper() is appropriate when processing the
locale-specific string for a TMDAY specification; but plain DAY is not
supposed to be locale-dependent, so we probably should use an ASCII-only
upcasing rule in the non-TM code path.

Anybody have an opinion on whether to back-patch such a fix?  It seems
conceivable that somebody out there is relying on the current behavior.
OTOH, I believe that only Turkish UTF8 locales exhibit this behavior
(the single-byte-encoding code path in str_toupper acts differently for
historical reasons).  So it's pretty inconsistent as it stands.

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: BUG #7853: Incorrect statistics in table with many dead rows.
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: postmaster --help does not show --config-file