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" <alvhe...@commandprompt.com>
Tom Lane wrote:
Alvaro Herrera <alvhe...@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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
