On Wed, 23 Mar 2005, Sim Zacks wrote:
> In any case, there are 2 correct solutions to the problem for the case of
> postgresql.
> 1) Database standard - postgresql chooses a newline standard and every
> client must support that if they support postgresql. Either put the onus on
> the client developers to override the OS standard and support the postgresql
> standard, or have the db convert the incoming newlines into the db standard.
>
> 2) Server's OS - the server must convert any new lines coming in to the
> standard that it expects. This is similar to an ftp client that converts
> newlines on the transfer. That means that data sent to a Windows server with
> an LF will be converted to a CRLF and vice versa.
>
> The data restore function will also have to follow the above procedures to
> make sure you can take data from one server to the other without
> compromising integrity.
>
> Without one of these solutions, PostGreSQL is not compatible between servers
> and clients.
> A query written on any client should return the same result. The query being
> the visible appearance on the screen. That is what the users would expect to
> have returned.
Yeah, those were my points.
The _open_ problems are:
- 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. [*]
- 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"? What if
the user selects for the messages longer than 990? What is the expected
answer, from the user standpoint?
There's no easy solution I think.
[*] This is _way_ more common than you'd think. RFC2822, internet message
format, says lines are CRFL separated. It happens sometimes that a message
contains a NL or a CR alone.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
