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

From Andrew Dunstan
Subject Re: Bad Data back Door
Date
Msg-id 50708E87.6080300@dunslane.net
Whole thread Raw
In response to Re: Bad Data back Door  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 10/06/2012 03:35 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.)
>> 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.
>
>


Exactly.

We've done quite a lot of work tightening the ways that badly encoded
data can enter the database over the years. It's a never ending game of
whack-a-mole. There aren't any easy answers.

cheers

andrew




pgsql-hackers by date:

Previous
From: Atri Sharma
Date:
Subject: Re: Regarding identifying a foreign scan
Next
From: Tom Lane
Date:
Subject: Re: Regarding identifying a foreign scan