Re: Bad Data back Door
От | Andrew Dunstan |
---|---|
Тема | Re: Bad Data back Door |
Дата | |
Msg-id | 50708E87.6080300@dunslane.net обсуждение исходный текст |
Ответ на | Re: Bad Data back Door (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 10/06/2012 03:35 PM, Tom Lane wrote: > "David E. Wheeler" <david@justatheory.com> writes: >> On Oct 5, 2012, at 6:12 PM, Tom Lane <tgl@sss.pgh.pa.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, it’s Oracle that’s lying about the encoding ofthose text 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. > 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. > > Exactly. We've done quite a lot of work tightening the ways that badly encoded data can enter the database over the years. It's a never ending game of whack-a-mole. There aren't any easy answers. cheers andrew
В списке pgsql-hackers по дате отправления: