Thread: Perl interfacing to old and new backends.
I've got a server currently running postgresql 7.0.2 and I of course want to use the latest and greatest production release (well 7.3.1 at least). The thing being that this is one of those RAQ systems and they have alsorts of wierd system admin things, mostly through a web interface, so I don't really want to just replace the perl modules with ones linked against the new postgresql. I'm also pretty certain that should I be silly enough to try and install the modules from CPAN then they will trash the old versions. Anyone got any hints as to how to run two sets of perl --> pgsql modules without doing a completely new perl install in a different tree? Alternatively, anyone know if a RAQ4 with a Linux 2.2 series kernel dated November 2001 actually uses PostgreSQL for any of it's fancy management tools? I've a suspicion that it doesn't but who knows with this setup. -- Nigel J. Andrews
On Thu, 20 Feb 2003, Nigel J. Andrews wrote: > I've got a server currently running postgresql 7.0.2 and I of course want to > use the latest and greatest production release (well 7.3.1 at least). > > The thing being that this is one of those RAQ systems and they have alsorts of > wierd system admin things, mostly through a web interface, so I don't really > want to just replace the perl modules with ones linked against the new > postgresql. I'm also pretty certain that should I be silly enough to try and > install the modules from CPAN then they will trash the old versions. > > Anyone got any hints as to how to run two sets of perl --> pgsql modules > without doing a completely new perl install in a different tree? > Try installing the module in another directory and 'use lib q(path_to_mod);'I'd watch trying to run both versions undersomething like mod_perl, however, because things will get very ugly very quickly. 'perl Makefile.PL PREFIX=somewhere' should get you most of the way there, IIRC. For more info: 'perldoc ExtUtils::MakeMaker' The other possibility is to change the name of the module from DBD::Pg to something else DBD::TestPg or something like that. In this case you would be able to use both in the same script or in a mod_perl env. -r
On Thu, 20 Feb 2003, Rudy Lippan wrote: > On Thu, 20 Feb 2003, Nigel J. Andrews wrote: > > > I've got a server currently running postgresql 7.0.2 and I of course want to > > use the latest and greatest production release (well 7.3.1 at least). > > > > The thing being that this is one of those RAQ systems and they have alsorts of > > wierd system admin things, mostly through a web interface, so I don't really > > want to just replace the perl modules with ones linked against the new > > postgresql. I'm also pretty certain that should I be silly enough to try and > > install the modules from CPAN then they will trash the old versions. > > > > Anyone got any hints as to how to run two sets of perl --> pgsql modules > > without doing a completely new perl install in a different tree? > > > > Try installing the module in another directory and 'use lib q(path_to_mod);' > I'd watch trying to run both versions under something like mod_perl, > however, because things will get very ugly very quickly. > > 'perl Makefile.PL PREFIX=somewhere' should get you most of the way there, > IIRC. For more info: 'perldoc ExtUtils::MakeMaker' Thanks very much. I actually got there myself having noted the word PREFIX going by in the CPAN config sequence but I probably should read that perldoc as it was really a flying blind type thing. > The other possibility is to change the name of the module from DBD::Pg to > something else DBD::TestPg or something like that. In this case you would > be able to use both in the same script or in a mod_perl env. I never thought of that. As I built a new perl anyway (5.8) I'm prpbably locked out of using mod_perl now anyway. BTW, the system does seem to use the postgres installation it had. There's a cobalt database. I didn't fancy trying to upgrade it since I have no idea what the system is using it for. -- Nigel J. Andrews