<!--

$Header: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v 2.20 2003/08/31 17:32:19 petere Exp $

$Header: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v 2.20.2.1 2010/05/13 16:44:35 adunstan Exp $

-->

<chapter id="plperl">

If the above function was created by a superuser using the language

<literal>plperlu</>, execution would succeed.

</para>

</sect1>

<note>

<para>

For security reasons, to stop a leak of privileged operations from

<application>PL/PerlU</> to <application>PL/Perl</>, these two languages

have to run in separate instances of the Perl interpreter. If your

Perl installation has been appropriately compiled, this is not a problem.

However, not all installations are compiled with the requisite flags.

If <productname>PostgreSQL</> detects that this is the case then it will

not start a second interpreter, but instead create an error. In

consequence, in such an installation, you cannot use both

<application>PL/PerlU</> and <application>PL/Perl</> in the same backend

process. The remedy for this is to obtain a Perl installation created

with the appropriate flags, namely either <literal>usemultiplicity</> or

both <literal>usethreads</> and <literal>useithreads</>.

For more details,see the <literal>perlembed</> manual page.

</para>

</note>

</sect1>

<sect1 id="plperl-missing">

<title>Missing Features</title>

subdir = src/pl/plperl

top_builddir = ../../..

overrideCFLAGS :=$(filter-out -Wall -Wmissing-declarations -Wmissing-prototypes,$(CFLAGS))

overrideCPPFLAGS := -I$(srcdir) -I$(perl_archlibexp)/CORE$(CPPFLAGS)

overrideCPPFLAGS := -I. -I$(srcdir) -I$(perl_archlibexp)/CORE$(CPPFLAGS)

NAME = plperl

all: all-lib

plperl.o: plperl_opmask.h

plperl_opmask.h: plperl_opmask.pl

SPI.c: SPI.xs

$(PERL)$(perl_privlibexp)/ExtUtils/xsubpp -typemap$(perl_privlibexp)/ExtUtils/typemap$<>$@

rm -f$(DESTDIR)$(pkglibdir)/plperl$(DLSUFFIX)

cleandistcleanmaintainer-clean: clean-lib

rm -f SPI.c$(OBJS)

rm -f SPI.c$(OBJS) plperl_opmask.h

else # can't build