> - what about storing a signed document? it's possible that newline
> conversion makes the signature invalid. How would you restore the
original
> document? Before you answer think of:
> a) a client running on a platform different from the one that inserted
> the document;
> b) a document with _mixed_ newline types, such as a windows text with
> enmbedded bare \n or \r. [*]
I think there can be a difference between ASCII (text) data and binary data.
Think of the example of FTP again, which handles this very nicely. Binary
data should not have new lines converted. There is a well accepted
difference between binary and ascii. Text can be defined as being completely
readable by the human eye. If there happens to be binary data embedded in
the text, that is not a part of the text but rather supports the text. Any
data that can not have the binary data modified becuase it will render the
data unusable is not really text.
I am not familiar with signed documents, but I would question how they are
currently handled in a cross OS environment. You may as well ask the same
question about how you would handle a jpeg image. Obviously you will not
want to look for LF and replace it with CRLF because in that data LF does
not mean skip a line.
> what about any other function that may be affected by newline style?
> I mean, the user may insert a text that he knows it's 1000 chars long,
> and finds that PG thinks it's only 980. Is this "consistent"?
If a user inserts a string that he thinks is 1000 charcters long and across
PG implementations and documentation it is considered to be 980 charcters
long, then that is consistent. If he enters a string that he thinks is 1000
characters long and sometimes PG thinks that it is 980, sometimes 1000 and
sometimes 1050 that is not consistent.