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 \_