Re: [HACKERS] perl interface bug? - Mailing list pgsql-hackers

From Brook Milligan
Subject Re: [HACKERS] perl interface bug?
Date
Msg-id 199810192258.QAA09626@trillium.nmsu.edu
Whole thread Raw
In response to Re: [HACKERS] perl interface bug?  (Edmund Mergl <E.Mergl@bawue.de>)
List pgsql-hackers
I envision 2 general classes of postgresql installers:  1) root, and
2) nonroot users wishing to try/use postgresql.

In the case of root sysadmins, everything (including perl) should
install out of the box.  It does so now without affecting the
standalone perl interface installation.

In the case of nonroot installers, there are two subcases: 2a) perl is
installed in system directories with only root access, and 2b) perl
was installed in some other place by the postgresql installer.

In case 2b, again there is no problem.  The install (with a suitable
--prefix=... argument to configure) should proceed unimpeded.

In case 2a, postgresql is installable under control of the
--prefix=... argument, but there will be a conflict when perl is
installed do to lack of access to the perl filesystem for the perl
interface shared library.  In this case, the installer can install
postgresql WITHOUT the --with-perl option to configure.  Later,
someone with root permission can do the 
cd interfaces/perl5perl Makefile.PLmakemake testmake install

sequence.  I don't see any situations that lose here.  Am I missing
something?

In conclusion, I see our current perl interface handling as addressing
all the relevant conditions (thanks to Tom Lane for finishing it
up!).

Cheers,
Brook


pgsql-hackers by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] Postgres - Y2K Compliant....Yes or No
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: inet/cidr/bind