Module Portability

From: Paul Ramsey <pramsey(at)refractions(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Module Portability
Date: 2002-08-01 20:01:15
Message-ID: 3D49938B.58B7B576@refractions.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)refractions(dot)net
| Phone: (250) 885-0632
\_

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-08-01 20:01:49 Re: Open 7.3 items
Previous Message Stephan Szabo 2002-08-01 20:01:00 Re: Rules and Views