Re: Bad Data back Door - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bad Data back Door
Date
Msg-id 7437.1349552119@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bad Data back Door  ("David E. Wheeler" <david@justatheory.com>)
Responses Re: Bad Data back Door  (Andrew Dunstan <andrew@dunslane.net>)
Re: Bad Data back Door  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
List pgsql-hackers
"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.)

> I agree that this is a bug in oracle_fdw (well, potentially; ultimately, it�s Oracle that�s lying about the encoding
ofthose text values). But I think that it would be much more useful overall -- not to mention more database-like -- for
PostgreSQLto provide a way to enforce it. That is, to consider foreign tables to be an input like COPY or SQL, and to
validatevalues before displaying them.
 

It is the FDW's responsibility to deal with this.  We expect it to hand
back valid tuples; it is not reasonable to disassemble them looking for
mistakes (and we couldn't catch most mistakes, anyway).  If the
interface were defined in terms of text, we could do checking above the
FDW level ... but it isn't.
        regards, tom lane



pgsql-hackers by date:

Previous
From: John R Pierce
Date:
Subject: Re: Bad Data back Door
Next
From: Simon Riggs
Date:
Subject: Re: Bugs in CREATE/DROP INDEX CONCURRENTLY