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.
_____/ _____/ _/ [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
