Hi.Ummm, I present is not understood by the reason of Japanese. ... Therefore, It was made into the Spanish case. I know that Alvaro-san will understand Spanish well.
==postgresql.conf==lc_messages= 'es' server.log of a patch before and after was applied. Please see it.
Regards, Hiroshi Saito
----- Original Message ----- From: "Hiroshi Saito" <z-sa...@guitar.ocn.ne.jp>
Hi Peter-san.I see the problem for being an original domain in plpgsql. It differs from what codeset meant at postmaster by Japanese windows.... Please see, this look at the problem on which SJIS enters into a message. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/plpgsql/before_plpgsql_server.log This state is the following. ==lc_messages=ja server_encoding=utf-8 == Therefore, it needs to be codeset called for an original domain. It is the procedure in whichonly a server module must correspond. Then, It is solvable by this patch. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/plpgsql/after_plpgsql_server.logPlease take this into consideration. Tahnks.Regards, Hiroshi Saito----- Original Message ----- From: "Peter Eisentraut" <pete...@gmx.net>Alvaro Herrera wrote:Peter Eisentraut wrote:Log Message: ----------- Redefine _() to dgettext() instead of gettext() so that it uses the plpgsql text domain, instead of the postgres one (or whatever the default may be).Hmm, so is this needed on all other PLs too?In principle yes. Or call dgettext() explicitly, which is also done in some cases. However, in most cases messages are issued through ereport(), which handles this automatically (which you implemented, I recall).
plpgsql_es_before.log
Description: Binary data
plpgsql_es_after.log
Description: Binary data
plpgsql_test.sql
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
