Re: New user: Windows, Postgresql, Python - Mailing list pgsql-general

From Marco Colombo
Subject Re: New user: Windows, Postgresql, Python
Date
Msg-id Pine.LNX.4.61.0503161717290.20758@Megathlon.ESI
Whole thread Raw
In response to Re: New user: Windows, Postgresql, Python  (Michael Fuhr <mike@fuhr.org>)
Responses Re: plpython function problem workaround  (Michael Fuhr <mike@fuhr.org>)
List pgsql-general
On Wed, 16 Mar 2005, Michael Fuhr wrote:

> On Wed, Mar 16, 2005 at 04:17:51PM +0100, Marco Colombo wrote:
>>
>>     aprogram = "x = 1\nprint x\n";
>>     printf(aprogram);
>>     PyRun_SimpleString(aprogram);
>>
>> See? THIS program requires compile-time or run-time checks. You
>> can't run it on Windows, or Mac: it'll write garbage to the screen
>> (something that looks like garbage, that is).
>
> Are you sure about that?  It's been forever since I programmed in
> a Microsoft environment, but as I recall, I/O streams opened in
> "text mode" do automatic translations between \n and \r\n.

No I wasn't sure and I actually was wrong. I've never programmed under
Windows.  I've just learned something.

Apparently, as far as Python is concerned, the platform presents \n
at C level, so it makes sense for PyRun_SimpleString() to expect \n
as line terminator. Still I don't understand when the lexxer would
use \r\n as pysical line ending on Windows, but I can live with it. :-)

It seems that any client application under Windows is likely to use
only \n-delimited text, as long as it uses stdio functions and text
mode. Problems arise when it gets text from some other source. But since
at C level text is expected to be \n-delimited, the application should
take care of the conversion as soon as it receives the data.

I think that if we want to be conservative, any input that is supposed
to be treated (actively) as text by the server, should be \n-delimited.
That includes any function source.

I'm against to any on-the-fly conversion, now.
I don't like the idea of PostgreSQL accepting input in one form
(\r\n) and providing output in a different form (\n). Also think of
a function definition with mixed \r\n and \n lines: we'd have no way
to reconstruct the original input. I think we should just state that
text used for function definitions is \n-delimited. Some languages may
accept \r\n as well, but that's undocumented side effect, and bad practice.

Now that I learned that C programs on Windows are expected to handle
\n-delimited text, I can't think of any reason why an application should
send \r\n-delimited text via libpq as a function definition, unless
the programmer forgot to perform the "standard" \r\n to \n conversion
somewhere.

.TM.
--
       ____/  ____/   /
      /      /       /            Marco Colombo
     ___/  ___  /   /              Technical Manager
    /          /   /             ESI s.r.l.
  _____/ _____/  _/               Colombo@ESI.it

pgsql-general by date:

Previous
From: Richard Huxton
Date:
Subject: Re: 2 questions about types
Next
From: Adam Treat
Date:
Subject: dataKiosk 0.6 released