Re: syslogger line-end processing infelicity
От | Magnus Hagander |
---|---|
Тема | Re: syslogger line-end processing infelicity |
Дата | |
Msg-id | 46609342.5080508@hagander.net обсуждение исходный текст |
Ответ на | syslogger line-end processing infelicity (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: syslogger line-end processing infelicity
|
Список | pgsql-hackers |
Andrew Dunstan wrote: > > I have been looking at the syslogger code in connection with the CSV log > output proposal, and I'm quite concerned about the way it translates > every \n into \r\n for Windows output. This has several problems, not > least of which is that we can by no means assume that every \n has no > semantic significance. Consider the following: > > INSERT INTO mytable (textfield) VALUES ($$abc > def$$); > > Now if the line ending there is in fact \r\n we will output \r\r\n for > it, and if it is just \n we will output \r\n, and in neither case will > we be logging what is actually inserted. > > My first thought is that we might need to distinguish between newlines > embedded in the query, which shouldn't be touched, from the newline at > the end of the log line. > > My second thought is that we should quite possibly abandon this > translation altogether - we know that our COPY code is quite happy with > either style of line ending, as long as the file is consistent, and also > many Windows programs will quite happily read files with Unix style line > endings (e.g. Wordpad, although not Notepad). Agreed. We shouldn't touch the data. Every editor I know on windows *except* notepad can deal just fine with Unix line endings, and if you're logging your queries your logfile will be too large to work well in notepad anyway :-) //Magnus
В списке pgsql-hackers по дате отправления: