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....
Changing this behavior in Python would break backwards compatibility. In particular, the exec() function accepts strings that have already been unescaped:
>>> exec('print """\n\r\n\r\n"""')In the above example, the exec function is being passed a string containing carridge returns and line feeds - not '\n' and '\r' character sequences.
It is too late for the Python 2.3 series anyway - 2.3.5 is being released Jan 26th and there won't be a 2.3.6. If it was championed and it decided that the above example is a bug and not a feature and a patch produced, it could get into 2.4.1 due April and 2.5+
I suspect this means fixing this problem in plpythonu for 8.1.
-- Stuart Bishop <stuart@xxxxxxxxxxxxxxxx> http://www.stuartbishop.net/
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
