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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: cvs checkout pgsql
Следующее
От: Vince Vielhaber
Дата:
Сообщение: Re: cvs checkout pgsql