Module Portability

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