On Tue, 2 Dec 2003, Lamar Owen wrote:
> Because Pg is no longer distributed as a part of the main tarball, but a
> contrib is being distributed that requires it. This is an issue with the
> main tarball, not with the RPM packaging, IMO. Someone needs to step up to
> the plate and build a Pg RPM that provides the Pg module, one that would
> replace the old postgresql-perl subpackage (which no longer exists). If no
> one else can do this, I can, but it's not high on my list of priorities.
What you have a life? :-) OK it is slowly seeping in into my gray
matter. This 'perl(Pg)' is what the was/is/can be replaced by DBI and
DBD::Pg. Is this correct? I had it in my mind this was the plperl and
plperlu stuff.
> > I only disabled tcl, tkpkg, pltcl, and python in the SPEC file. I could
> > not install the contrib stuff but I really want the plperl and plperlu
> > languages.
>
> plperl.so is in the postgresql-pl package. The Pg module is a client side
> deal, not a server side PL.
Right, like I guesstimated above. Is 'the postgresql-pl package' a
separate RPM or part of the main or server RPM?
> The Rserv contrib is the only thing, AFAIK, that requires the old Pg module.
> I don't really want to not distribute it, since I have historically
> distributed the contrib tree intact. That may have to change, I guess.
Well I vote (if that is an option) for making it simple enough for me to
install. *REALLY* simple!
Rod
--
"Open Source Software - Usually you get more than you pay for..."
"Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL"
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
