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).

My third thought is that even so my first thought has some virtue :-). We really need to ensure that we only rotate files when we are at a genuine end of log line - the situation that Greg Smith described of having the rotator chop a line in two between two files seem wholly unacceptable.

Thoughts?


cheers

andrew


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to