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 of
thosetext 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
