From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Adrian Klaver <aklaver(at)comcast(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hong Yuan <hongyuan(at)homemaster(dot)cn>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Multiline plpython procedure |
Date: | 2005-01-19 04:01:36 |
Message-ID: | 20050119040136.GA56212@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Jan 18, 2005 at 07:34:59PM -0800, Adrian Klaver wrote:
> Actually universal newline support seems to be covered by the following PEP
> and is present in the version of Python(2.3) I am running.
> http://www.python.org/peps/pep-0278.txt
I see the following in the PEP:
There is no support for universal newlines in strings passed to
eval() or exec. It is envisioned that such strings always have the
standard \n line feed, if the strings come from a file that file can
be read with universal newlines.
Does the above mean that the PyRun_*() family doesn't have universal
newline support? Or at least that some members of the family don't?
That would explain why the simple C program I tested failed.
http://archives.postgresql.org/pgsql-general/2005-01/msg00876.php
> I would tend to agree with Hong Yuan that the problem exists in plpythonu's
> handling of newlines.
If Python's behavior is intentional then the newline burden would
seem to be on the user or on plpythonu. I think Tom's point is
that that's just silly....
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-01-19 04:11:16 | Re: Index optimization ? |
Previous Message | Chris Smith | 2005-01-19 03:39:22 | Re: Easy transaction question |