Re: Bad Data back Door
От | Andrew Dunstan |
---|---|
Тема | Re: Bad Data back Door |
Дата | |
Msg-id | 50731B73.1030408@dunslane.net обсуждение исходный текст |
Ответ на | Re: Bad Data back Door (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 10/08/2012 02:13 PM, Tom Lane wrote: > "David E. Wheeler" <david@justatheory.com> writes: >> On Oct 5, 2012, at 6:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Now, having said that, I think it has to be the reponsibility of the FDW >>> to apply any required check ... which makes this a bug report against >>> oracle_fdw, not the core system. (FWIW, contrib/file_fdw depends on the >>> COPY code, which will check encoding.) >> FWIW, I believe that dblink does not check encoding. > In dblink's case, that boils down to trusting a remote instance of > Postgres to get this right, which doesn't seem totally unreasonable. > But I wouldn't object to adding checks there if someone wanted to submit > a patch. It does do: PQsetClientEncoding(conn, GetDatabaseEncodingName()); I'd be mildly reluctant to do anything more except possibly as an option, unless it could be shown to have minimal performance impact. cheers andrew
В списке pgsql-hackers по дате отправления: