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

Thu, 01 Aug 2002 13:01:15 -0700
Paul Ramsey <pramsey@refractions.net>
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


Thu, 1 Aug 2002 23:02:00 +0300 (GMT)
Oleg Bartunov <oleg@sai.msu.su>
Re: Module Portability
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
     \_

Thu, 01 Aug 2002 13:08:12 -0700
Paul Ramsey <pramsey@refractions.net>
Re: Module Portability
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


Thu, 1 Aug 2002 22:36:50 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Module Portability
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
     \_

Thu, 01 Aug 2002 14:04:35 -0700
Paul Ramsey <pramsey@refractions.net>
Re: Module Portability
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
> 


Fri, 2 Aug 2002 09:37:43 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: Module Portability