Re: Inconsistent PL error handling

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.