Just use $libdir... Chris
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Ramsey > Sent: Friday, 2 August 2002 4:01 AM > To: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > | Phone: (250) 885-0632 > \_ > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly