On 5/9/13 5:40 PM, Dave Page wrote: > Whilst working on a build issue with pl/python, I noticed an > inconsistency in the way the server reacts to attempts to use PLs for > which the interpreter doesn't exist. Not sure how feasible it would be > to fix this, but the Python case doesn't seem ideal: > > psql.bin (9.3beta1) > Type "help" for help. > > postgres=# CREATE LANGUAGE plperl; > ERROR: could not load library > "/opt/PostgreSQL/9.3/lib/postgresql/plperl.so": libperl.so: cannot > open shared object file: No such file or directory > postgres=# CREATE LANGUAGE plpython3u; > CREATE LANGUAGE > postgres=# CREATE FUNCTION pyversion() RETURNS text AS > $$ > import sys > return sys.version > $$ LANGUAGE 'plpython3u'; > The connection to the server was lost. Attempting reset: Failed. > !>
I can't reproduce that. For me, a missing plpython install results in the same kind of error message as a missing plperl install. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
