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