Re: multi line text data/query ?bug? - Mailing list pgsql-general

From Marco Colombo
Subject Re: multi line text data/query ?bug?
Date
Msg-id Pine.LNX.4.61.0503231131590.26346@Megathlon.ESI
Whole thread Raw
In response to Re: multi line text data/query ?bug?  ("Sim Zacks" <sim@compulab.co.il>)
List pgsql-general
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

pgsql-general by date:

Previous
From: "Sim Zacks"
Date:
Subject: Re: multi line text data/query ?bug?
Next
From: Sean Davis
Date:
Subject: Re: Question about function body checking and 8.1