Thread: Inconsistent PL error handling

Inconsistent PL error handling

From
Dave Page
Date:
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

Re: Inconsistent PL error handling

From
Peter Eisentraut
Date:
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.