syslogger line-end processing infelicity

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