Skip site navigation (1) Skip section navigation (2)

Re: Bad Data back Door

From: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bad Data back Door
Date: 2012-10-06 17:34:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Oct 5, 2012, at 6:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 of those text values). But I think that it would be much more useful overall -- not to mention more database-like -- for PostgreSQL to provide a way to enforce it. That is, to consider foreign tables to be an input like COPY or SQL, and to validate values before displaying them.



In response to


pgsql-hackers by date

Next:From: Atri SharmaDate: 2012-10-06 17:37:02
Subject: Re: Bad Data back Door
Previous:From: Tom LaneDate: 2012-10-06 14:59:47
Subject: Re: Add FET to Default and Europe.txt

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group