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

From Atri Sharma
Subject Re: Bad Data back Door
Date
Msg-id CAOeZVie_XK=p3f2NamX91fBQwzAzu4Gk_Wubcn8aybeWwXxO9g@mail.gmail.com
Whole thread Raw
In response to Re: Bad Data back Door  ("David E. Wheeler" <david@justatheory.com>)
List pgsql-hackers
On Sat, Oct 6, 2012 at 1:34 PM, David E. Wheeler <david@justatheory.com> wrote:
> On Oct 5, 2012, at 6:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> Probably not so much "assumed" as "nobody thought about it".  In
>> e.g. plperl we expend the cycles to do encoding validity checking on
>> *every* string entering the system from Perl.  I'm not sure why foreign
>> tables ought to get a pass on that, especially when you consider the
>> communication overhead that the encoding check would be amortized
>> against.
>
> Yes, that’s what I was thinking.
>
>> 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. 
>
> Best,
>
> David
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


+1
--
Regards,

Atri
l'apprenant



pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Bad Data back Door
Next
From: Atri Sharma
Date:
Subject: Regarding identifying a foreign scan