Обсуждение: Module Portability
All this talk of modularity reminds me of a pet peeve: doing dump/restore upgrades when your databases include extension functions is highly clunky, because extension functions include the fully qualified path to the linking library. So, for example create function geometry_in(opaque) RETURNS GEOMETRY AS '/opt/pgsql72/lib/contrib/libpostgis.so.0.7' LANGUAGE 'c'with (isstrict); If I do a pg_dumpall on an old database and try to pipe into a new database, things can get messy pretty fast. It would be nice if pgsql had a 'default library location' which it tried to load linking libraries from, in much the same way apache uses libexec. Then my definition could just be: create function geometry_in(opaque) RETURNS GEOMETRY AS 'libpostgis.so.0.7' LANGUAGE 'c' with (isstrict); Which would be alot more portable across installations. I mean, right now I can render my database inoperative just by moving my executable installation tree to a new path. Nice. -- __ / | Paul Ramsey | Refractions Research | Email: pramsey@refractions.net | Phone: (250) 885-0632 \_
Contrib modules does have such possibility. For example: CREATE FUNCTION ltree_in(opaque) RETURNS opaque AS 'MODULE_PATHNAME' LANGUAGE 'c' with (isstrict); Oleg On Thu, 1 Aug 2002, Paul Ramsey wrote: > All this talk of modularity reminds me of a pet peeve: doing > dump/restore upgrades when your databases include extension functions is > highly clunky, because extension functions include the fully qualified > path to the linking library. So, for example > > create function geometry_in(opaque) > RETURNS GEOMETRY > AS '/opt/pgsql72/lib/contrib/libpostgis.so.0.7' > LANGUAGE 'c' with (isstrict); > > If I do a pg_dumpall on an old database and try to pipe into a new > database, things can get messy pretty fast. It would be nice if pgsql > had a 'default library location' which it tried to load linking > libraries from, in much the same way apache uses libexec. Then my > definition could just be: > > create function geometry_in(opaque) > RETURNS GEOMETRY > AS 'libpostgis.so.0.7' > LANGUAGE 'c' with (isstrict); > > Which would be alot more portable across installations. I mean, right > now I can render my database inoperative just by moving my executable > installation tree to a new path. Nice. > > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Correct me if I am wrong (I often am) but isn't MODULE_PATHNAME replaced by the fully qualified module path during the build process? I mean, the source code is movable, but a running installed system, with real data, is not movable, because MODULE_PATHNAME gets mapped to /usr/local/mypgsql/lib/blah.so or somesuch. Oleg Bartunov wrote: > > Contrib modules does have such possibility. > For example: > > CREATE FUNCTION ltree_in(opaque) > RETURNS opaque > AS 'MODULE_PATHNAME' > LANGUAGE 'c' with (isstrict); > > Oleg > On Thu, 1 Aug 2002, Paul Ramsey wrote: > > > All this talk of modularity reminds me of a pet peeve: doing > > dump/restore upgrades when your databases include extension functions is > > highly clunky, because extension functions include the fully qualified > > path to the linking library. So, for example > > > > create function geometry_in(opaque) > > RETURNS GEOMETRY > > AS '/opt/pgsql72/lib/contrib/libpostgis.so.0.7' > > LANGUAGE 'c' with (isstrict); > > > > If I do a pg_dumpall on an old database and try to pipe into a new > > database, things can get messy pretty fast. It would be nice if pgsql > > had a 'default library location' which it tried to load linking > > libraries from, in much the same way apache uses libexec. Then my > > definition could just be: > > > > create function geometry_in(opaque) > > RETURNS GEOMETRY > > AS 'libpostgis.so.0.7' > > LANGUAGE 'c' with (isstrict); > > > > Which would be alot more portable across installations. I mean, right > > now I can render my database inoperative just by moving my executable > > installation tree to a new path. Nice. > > > > > > Regards, > Oleg > _____________________________________________________________ > Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > Sternberg Astronomical Institute, Moscow University (Russia) > Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ > phone: +007(095)939-16-83, +007(095)939-23-83 -- __ / | Paul Ramsey | Refractions Research | Email: pramsey@refractions.net | Phone: (250) 885-0632 \_
Paul Ramsey writes: > It would be nice if pgsql had a 'default library location' Sure. That's why it was implemented in 7.2. -- Peter Eisentraut peter_e@gmx.net
Color me embarrased. / Peter Eisentraut wrote: > > Paul Ramsey writes: > > > It would be nice if pgsql had a 'default library location' > > Sure. That's why it was implemented in 7.2. > > -- > Peter Eisentraut peter_e@gmx.net -- __ / | Paul Ramsey | Refractions Research | Email: pramsey@refractions.net | Phone: (250) 885-0632 \_
Just use $libdir... Chris > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Paul Ramsey > Sent: Friday, 2 August 2002 4:01 AM > To: pgsql-hackers@postgresql.org > Subject: [HACKERS] Module Portability > > > All this talk of modularity reminds me of a pet peeve: doing > dump/restore upgrades when your databases include extension functions is > highly clunky, because extension functions include the fully qualified > path to the linking library. So, for example > > create function geometry_in(opaque) > RETURNS GEOMETRY > AS '/opt/pgsql72/lib/contrib/libpostgis.so.0.7' > LANGUAGE 'c' with (isstrict); > > If I do a pg_dumpall on an old database and try to pipe into a new > database, things can get messy pretty fast. It would be nice if pgsql > had a 'default library location' which it tried to load linking > libraries from, in much the same way apache uses libexec. Then my > definition could just be: > > create function geometry_in(opaque) > RETURNS GEOMETRY > AS 'libpostgis.so.0.7' > LANGUAGE 'c' with (isstrict); > > Which would be alot more portable across installations. I mean, right > now I can render my database inoperative just by moving my executable > installation tree to a new path. Nice. > > -- > __ > / > | Paul Ramsey > | Refractions Research > | Email: pramsey@refractions.net > | Phone: (250) 885-0632 > \_ > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html >