Re: restore whoes
От | Tom Lane |
---|---|
Тема | Re: restore whoes |
Дата | |
Msg-id | 15618.1013463240@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: restore whoes (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-admin |
Peter Eisentraut <peter_e@gmx.net> writes: > ISTM that this class of problem should be avoided by reading COPY input as > a text stream rather than a binary stream on all operating systems. > Doesn't that effectively guarantee that your program sees the end of the > line as "\n" only, no matter how it's actually stored? (1) No, that just guarantees that we have no control over the breakage or recovering from it. Our real problem is that COPY's data representation is not newline-translation-proof; opening up an additional place where newline translation might or might not occur cannot fix this problem, it can only make it worse. (2) On Unix machines, "text mode" I/O does not do anything different from binary mode anyway. Our problem is with pg_dump data that has temporarily left the Unix world and been munged in transit. We want to be able to deal with that whether or not the local libc has ever heard of \r\n newlines. regards, tom lane
В списке pgsql-admin по дате отправления: