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. !> The server was compiled with both Perl and Python support using the ActiveState packages on 64 bit Linux on the build machine, but the runtime machine had neither installed (as would often be the case for installer packages). -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs