pgsql: Redefine _() to dgettext() instead of gettext() so that it uses

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?

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).

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 which
only 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.log

Please take this into consideration.
Tahnks.

Regards,
Hiroshi Saito

----- Original Message -----
From: "Peter Eisentraut" <peter_e@gmx.net>

Hiroshi Saito wrote:

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.

Understood. In fact, after having a look at this patch and giving it a
little refactoring I think it's pretty obvious; right now we're calling
bind_textdomain_codeset only for the main domain, and with this patch we
also set it for all other domains we use.

Does this patch work for you?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@commandprompt.com> writes:

Understood. In fact, after having a look at this patch and giving it a
little refactoring I think it's pretty obvious; right now we're calling
bind_textdomain_codeset only for the main domain, and with this patch we
also set it for all other domains we use.

Does this patch work for you?

Seems like this comment needs to move into the new function:

* On Windows, we need to explicitly bind gettext to the correct
* encoding, because gettext() tends to get confused.

More generally, should we push the bindtextdomain calls themselves into
the new function (and perhaps call it something else than
SetDomainCodeSet)? Seems like logically this should be thought of as
all one operation, ie, it's not clear to me that it ever makes sense to
call bindtextdomain without also worrying about encoding.

regards, tom lane

Tom Lane wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

Understood. In fact, after having a look at this patch and giving it a
little refactoring I think it's pretty obvious; right now we're calling
bind_textdomain_codeset only for the main domain, and with this patch we
also set it for all other domains we use.

More generally, should we push the bindtextdomain calls themselves into
the new function (and perhaps call it something else than
SetDomainCodeSet)? Seems like logically this should be thought of as
all one operation, ie, it's not clear to me that it ever makes sense to
call bindtextdomain without also worrying about encoding.

I'm not sure that can be made to work easily. On the backend itself we
call bindtextdomain in set_pglocale_pgservice() which is also used by
programs in src/bin/. Shuffling things in there would be more involved
than seems worth.

As for names, how about pg_bind_textdomain_codeset?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Hi Alvaro-san.

Yeah, It seems that it saves also except pl. then, It also regards me as very good.
I tested just now, of course, it is very comfortable. :-)

== try ==
C:\work>psql -e -f plpgsql_test.sql
show client_encoding;
client_encoding
-----------------
latin1
(1 row)

show server_encoding;
server_encoding
-----------------
UTF8
(1 row)

set lc_messages to es;
SET
show lc_messages;
lc_messages
-------------
es
(1 row)

create function func1() returns int as '
begin
select "a;
end;
' language 'plpgsql';
psql:plpgsql_test.sql:10: ERROR: un identificador entre comillas est� inconcluso
CONTEXT: compilation of PL/pgSQL function "func1" near line 2

==/END

Thanks!

Regards,
Hiroshi Saito

----- Original Message -----
From: "Alvaro Herrera" <alvherre@commandprompt.com>

Hiroshi Saito wrote:

Hi Alvaro-san.

Yeah, It seems that it saves also except pl. then, It also regards me as very good.
I tested just now, of course, it is very comfortable. :-)

Thanks, Hiroshi-san. I just applied that last version.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support