Re: pgsql-server/ oc/src/sgml/ref/copy.sgml rc/bac ...
От | Bruce Momjian |
---|---|
Тема | Re: pgsql-server/ oc/src/sgml/ref/copy.sgml rc/bac ... |
Дата | |
Msg-id | 200304211544.h3LFi3k13656@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql-server/ oc/src/sgml/ref/copy.sgml rc/bac ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-committers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> suggest that you're thinking that way. What exactly do you have in > >> mind here? Certainly the client is not going to determine the > >> newline format for COPY TO STDOUT unless it does translation. > > > My idea was that if the client opens a file to dump the STDOUT data, it > > will opened in text mode, and that will have \r\n for Win32 and \n for > > Unix. > > But it would probably be a bad idea for the client to open such a file > in text mode. We are going to have COPY BINARY TO STDOUT/FROM STDIN > real soon now (like probably today or tomorrow ;-)). Unless the client > takes the trouble to determine whether the copy is text or binary, > opening the file in text mode will be the Wrong Thing. So I think that > a decision to always send LF on-the-wire will result in Windows users > seeing LF-newline dump files. Not sure how unhappy that will make them. > > I personally don't have a problem with the approach; I was just > wondering if it really does what you intend. I think that is fine. pg_dump is the one that uses STDIN/STDOUT the most, and that will open as text/binary as appropriate. I see now that pg_dump seems to only open in binary so I may have to look at that, but clearly it is only applications that should control this stuff --- the wire protocol should not. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-committers по дате отправления: