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  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: syslogger line-end processing infelicity
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Constraint exclusion oddity with composite index