Thread: Re: [COMMITTERS] 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>


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

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

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>


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

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