On Sat, Oct 6, 2012 at 1:34 PM, David E. Wheeler <da...@justatheory.com> wrote: > On Oct 5, 2012, at 6:12 PM, Tom Lane <t...@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 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 > > > > -- > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
