Re: plpythonu strange syntax error

On Fri, Feb 18, 2005 at 12:44:47PM +0100, Michele Bendazzoli wrote:
> > > Does the string that contains the Python code have carriage returns?
> > > Python is picky about that; there was a thread about it recently.
> > >
> > > http://archives.postgresql.org/pgsql-general/2005-01/msg00792.php
>
> I read the thread but they seem to have miss the point: there is not a
> platform issue here because postgresql, pgadmin and python are both
> running on the same machine (a windows 2003 server)!

PEP 278 (http://www.python.org/peps/pep-0278.txt) says this:

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.

If I'm interpreting that correctly, then regardless of platform, a
string containing code to be executed must end its lines with LF
(\n), not CRLF (\r\n). When running an ordinary Python script, a
CRLF => LF translation presumably happens as the script is read,
before the code is executed. You might not be getting that translation
when using pgAdmin. As I recall from the thread, there was also
concern about restoring a function that had been dumped with pg_dump.

Have you checked whether the plpythonu code contains carriage
returns? I forget if there's an easier way, but you could do
this:

SELECT replace(prosrc, '\r', 'CR')
FROM pg_proc
WHERE proname = 'foo';

I just created a plpythonu function with a carriage return and the
above command shows this:

replace
------------------
x = 1CR
return x
(1 row)

Trying to run the function fails:

SELECT foo();
ERROR: plpython: could not compile function "foo"
DETAIL: exceptions.SyntaxError: invalid syntax (line 2)

If I strip the carriage return from the function's prosrc column
then it works:

UPDATE pg_proc SET prosrc = replace(prosrc, '\r', '')
WHERE proname = 'foo';

SELECT foo();
foo
-----
1
(1 row)

You might try that to see if it works (be careful modifying system
tables -- I'd suggest using a transaction so you can ROLLBACK if
the update affected too many rows).

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/