| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Bad Data back Door |
| Date: | 2012-10-08 18:29:07 |
| Message-ID: | 50731B73.1030408@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/08/2012 02:13 PM, Tom Lane wrote:
> "David E. Wheeler" <david(at)justatheory(dot)com> writes:
>> On Oct 5, 2012, at 6:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2012-10-08 18:33:13 | Re: [v9.3] Row-Level Security |
| Previous Message | David E. Wheeler | 2012-10-08 18:23:05 | Re: Bad Data back Door |