Re: restore whoes
| От | Peter Eisentraut | 
|---|---|
| Тема | Re: restore whoes | 
| Дата | |
| Msg-id | Pine.LNX.4.30.0202111626280.1903-100000@peter.localdomain обсуждение исходный текст | 
| Ответ на | Re: restore whoes (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Ответы | Re: restore whoes | 
| Список | pgsql-admin | 
Tom Lane writes: > Simple: suppose the dumped data contains \ \n in the body of a field, > which is the currently-accepted representation for a data newline. > Microsoft munges this to \ \r \n, which will now be read by COPY IN as a > backslashed \r (ie, a data \r) followed by a non-escaped newline. 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? -- Peter Eisentraut peter_e@gmx.net
В списке pgsql-admin по дате отправления: