Inconsistent PL error handling

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(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs