Re: plpython function problem workaround - Mailing list pgsql-general

The following is how I understand it, but please let's delay further
discussion until someone tests the program under Windows.

On Mon, 14 Mar 2005, Michael Fuhr wrote:

> Hmmm...I think that would be inconsistent with previous reports.
> For example, in the following message, the poster said that everything
> (PostgreSQL, pgAdmin) was running on Windows 2003:
>
> http://archives.postgresql.org/pgsql-interfaces/2005-02/msg00066.php

I'm sorry, he's wrong.
The initial report was by Hong Yuan:
http://archives.postgresql.org/pgsql-general/2005-01/msg00792.php

later he clarified:
http://archives.postgresql.org/pgsql-general/2005-01/msg00858.php

"I am using pgAdmin III Version 1.2.0 under Chinese Windows XP, while
  the database is 7.4.6 under Linux."

BTW I just noticed someone else provided a simpler example:
http://archives.postgresql.org/pgsql-general/2005-01/msg00876.php

someone should try and complile those under windows.

> I suggested that he strip the CRs from pg_proc.prosrc and he said
> it worked:
>
> http://archives.postgresql.org/pgsql-interfaces/2005-03/msg00014.php
>
> It's not clear that the test in the second message was run on a
> Windows server (apparently pgAdmin was run on a Windows client),
> but I think the beginning of the message is saying that he didn't
> reply for so long because he didn't have access to a Windows server.
> From that I infer that he tried my suggestion and posted the results
> when he finally did get access to a customer's Windows server.  I
> could be misreading that, however.

I have no idea of where Michele Bendazzoli ran that code. He's not
the original poster, tho.

> A couple of months ago Stuart Bishop brought this issue up in
> python-dev.  Most of the thread is along the lines of "strip the
> carriage returns":
>
> http://mail.python.org/pipermail/python-dev/2005-January/051203.html

Sorry again, but he's assuming Unix on the server side, and
Windows or Mac on the client side.

>> If anyone manages to compile the following code on Windows...
> ...
>> I bet on windows the first program fails and the second is ok.
>
> Hopefully somebody will do a Windows test of the code you posted.
> I'd find it bizarre that the Python code embedded in a C program
> had to care whether it was running on *nix or Windows.

I find it perfectly consistent! Face it, _any_ C program that's handling
data of type _text_ has to know which platform it is running on. If you
don't like the behaviour of Python functions, think of printf().
C programmers under Windows are used to write:

     printf("Hello World!\r\n");

as much (old) Mac programmers write:

     printf("Hello World!\r");

and Unix programmers write:

     printf("Hello World!\n");

_ANY_ C program that processes multiline text input has to know which
platform it is running on, otherwise it reads or proceduces garbage.

Python just requires the input being text, which seems reasonable to me,
since, by design, a python program is more that just a sequence of ';'-
separated statements (ala C or Perl), with _optional_ intermixing
whitespaces. White spaces ('eol' included) do have a meaning in Python
syntax.

BTW, this attitude reminds me of PostgreSQL strict validation of input,
compared to more relaxed checking made by MySQL. I really don't feel
the need to enumerate the merits of input validation on this list.
Python functions want 'valid text' and the definition is platform
dependent, unfortunately. Why should it be relaxed, and accept invalid
text as input?

If you are to compile any unix text processing utility, such as grep,
on a mac, you'll have to change the source and have the program split
lines at \r (under windows, splitting lines at \n still works, but
leaves a spurious \r around). Python is the same, since it expects
programs as _text_.

The universal newline support is totally another matter. And it applies
to files only (it's a wrapper around file functions). It's a tool
for lazy programmers.

It is possible that in the feature the Python lexxer is changed to
recognize different line endings (since there's no valid case for a
\r at the end of a line that I can think of). But requiring the
input being text is not 'bizarre' at all.

The issue about text representation affects _any_ application.
Treating text as binary data is plain wrong, IMHO, and will always
lead to problems.

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