Module Portability
От | Paul Ramsey |
---|---|
Тема | Module Portability |
Дата | |
Msg-id | 3D49938B.58B7B576@refractions.net обсуждение исходный текст |
Ответы |
Re: Module Portability
Re: Module Portability Re: Module Portability |
Список | 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@refractions.net | Phone: (250) 885-0632 \_
В списке pgsql-hackers по дате отправления: