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
>