From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Joshua Tolley <eggyknap(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_execute_from_file review |
Date: | 2010-11-30 03:25:07 |
Message-ID: | AANLkTik6xJRnj6hj5fmt6Osp0rBB1qDu7UaY4w14-MiF@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 30, 2010 at 08:56, Alvaro Herrera
<alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-11-30 03:35:52 | Re: profiling connection overhead |
Previous Message | Robert Haas | 2010-11-30 03:19:22 | Re: DELETE with LIMIT (or my first hack) |