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: A1176DA3-B32B-4396-A820-78E7CF9C9C0F@justatheory.com (view raw or flat)
Thread:
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.

Best,

David



In response to

Responses

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-2014 The PostgreSQL Global Development Group