Re: pg_execute_from_file review
От | Itagaki Takahiro |
---|---|
Тема | Re: pg_execute_from_file review |
Дата | |
Msg-id | AANLkTik6xJRnj6hj5fmt6Osp0rBB1qDu7UaY4w14-MiF@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_execute_from_file review (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: pg_execute_from_file review
|
Список | pgsql-hackers |
On Tue, Nov 30, 2010 at 08:56, Alvaro Herrera <alvherre@commandprompt.com> wrote: >> > * I hope pg_execute_from_file (and pg_read_file) had an option >> > to specify an character encoding of the file. Especially, SJIS >> > is still used widely, but it is not a valid server encoding. >> >> So, what about client_encoding here, again? > > I tried this in an earlier iteration of this patch, and it works fine > (albeit with a Latin1 file in an UTF8 encoded database, but presumably > this is no different from any other pair of client/server encodings; > recoding took place correctly during execution). client_encoding won't work at all because read_sql_queries_from_file() uses pg_verifymbstr(), that is verify the input with *server_encoding*. Even if we replace it with pg_verify_mbstr(client_encoding, ...) and pg_do_encoding_conversion(from client_encoding to server_encoding), it still won't work well when error messages are raised. The client expects the original client encoding, but messages are sent in the file encoding. It would be a security hole. -- Itagaki Takahiro
В списке pgsql-hackers по дате отправления: