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
|
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: