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

Re: Bad Data back Door

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bad Data back Door
Date: 2012-10-06 19:35:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"David E. Wheeler" <david(at)justatheory(dot)com> writes:
> On Oct 5, 2012, at 6:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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, its Oracle thats 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.

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

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-10-06 19:35:47
Previous:From: John R PierceDate: 2012-10-06 19:13:02
Subject: Re: Bad Data back Door

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