Excuse me if i don't replay before, but i haven't the possibility to try
pgadmin in a windows system (it is located in the Customer's Firm).
Il giorno ven, 18-02-2005 alle 10:40 -0700, Michael Fuhr ha scritto:
cut
> 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).
Yes it works. So the problem is that in Windows system PGAdmin seem to
create the function with CRLF characters.
I don't know if it is a python fault or a pgadmin fault but I think that
someone should fix it, because it is impossibile to use PGAdmin to
create plpython function in windows ...
Thank you for the the quick and precise response.
ciao, Michele