Hello,
# SET lc_time = "de_DE.UTF-8";
# SELECT to_char('2011-03-04 00:00:01'::date, 'TMMonth YYYY');
to_char
-----------
MäRz 2011
I can reproduce the above when the database encoding is not UTF8 or
lc_ctype isn't a UTF8 locale.
Hm... encoding of the database is UTF8. The lc_ctype is 'C'.
Right, that was the same case I checked. In C locale, ä is not a
letter, so you get the above from the initcap transformation.
But don't that mean, that the translation of the timestamp to languages
with other umlauts should also be wrong. For example to "fr_FR.UTF-8"?
Possibly, I haven't checked. If they have any month names with
non-ASCII characters in the middle, they'd see the same thing.
You would certainly also get undesirable results from TMMONTH, since
it wouldn't know how to uppercase ä. In my view none of this is
a Postgres bug --- the correct fix is to use locale settings that
correspond to the behavior you want.
Hm... in my point of view it's a bug, but not necessarily a PG bug. My
desired result is the correct translated output in different languages.
Now i know that this is not possible, because i have to use the correct
lc_ctype for the entire database, which can't be changed after the
database-creation.
The only work-around seems to be to handle the translation myself.
That's very ugly and makes the use of TMMonth pointless, if you have to
take care of the result-output before you use the database.
Thanks to all for your time and help,
Torsten
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
