BUG #7913: TO_CHAR Function & Turkish collate

[a***@hotmail.com]

The following bug has been logged on the website:

Bug reference: 7913
Logged by: TO_CHAR Function & Turkish collate
Email address: ***@hotmail.com
PostgreSQL version: 9.2.0
Operating system: Linux
Description:

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.

Best regards,
Adnan DURSUN
Ankar/TURKEY

[Tom Lane]

Post by a***@hotmail.com
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

[Peter Eisentraut]

Post by Tom Lane
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.

Agreed.

Post by Tom Lane
Anybody have an opinion on whether to back-patch such a fix?

I think it's a bug that should be backpatched.

[Tom Lane]

Post by Peter Eisentraut

Post by Tom Lane
Anybody have an opinion on whether to back-patch such a fix?

I think it's a bug that should be backpatched.

Done. In addition to day/month names, I found that there were
case-folding hazards for timezone abbreviations ('tz' format)
and Roman numerals for numbers ('rn' format) ... though, curiously,
not for Roman numerals for months.

regards, tom lane

[Devrim GÜNDÜZ]

Hi,

Post by Tom Lane

Post by Peter Eisentraut
I think it's a bug that should be backpatched.

Done. In addition to day/month names, I found that there were
case-folding hazards for timezone abbreviations ('tz' format)
and Roman numerals for numbers ('rn' format) ... though, curiously,
not for Roman numerals for months.

Thanks!

Regards,

[Euler Taveira]

Post by Tom Lane
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.

Nope. I'm not aware of the Turkish weird rules. Mea culpa. :(

As you suggested, s/str_toupper/pg_toupper/ in the else block (no TM) is the
right fix. I'm not aware of another locale that would break if we apply such a
change in a stable branch. Are you want me to post a fix?

[Tom Lane]

Post by Euler Taveira
As you suggested, s/str_toupper/pg_toupper/ in the else block (no TM) is the
right fix. I'm not aware of another locale that would break if we apply such a
change in a stable branch. Are you want me to post a fix?

Thanks, but I have a fix mostly written already.

regards, tom lane