Re: Inline Extension
От | Dimitri Fontaine |
---|---|
Тема | Re: Inline Extension |
Дата | |
Msg-id | 87wr8ibdgn.fsf@hi-media-techno.com обсуждение исходный текст |
Ответ на | Re: Inline Extension (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Inline Extension
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: >> Ok, but then, what about .so files? Wouldn't it make sense to be able >> to ship also the executable modules needed, and if not, why not? > > Sure, that would be as useful as any other part of this feature. We'd > have to think carefully about how to make it secure, though: obviously > it's no good to let a non-superuser database owner install compiled C > code that gets loaded into the backend! The big problem is that .so are installed in directories where the system postgres user usually is not granted permissions to write, that's root business. It already has been asked before about allowing PostgreSQL to load .so from a non-root location, and I think that to be consistent with your view of the world it would be good to add that feature. Then there's no such beast as an “inline” extension so much as a way to install an extension from the protocol, without file system level access to the production server. This would need to be superuser only, of course. That opens up the possibility to ship the modules to any standby server too: the situation now is unfortunate in that create extension hstore on the primary then using it in some indexes means the standby has no means to use those index until you fix it and install the same extension files there. The module itself could be accepted as a bytea value and written at the right place, where the server knows to load it. Now you can dump/restore any extension fully, and we can even ship any extension in the WAL stream (a new message is needed though). The only remaining issue would be the default policy as far as including or avoiding an extension in the dump is concerned, and I would be ok with a default of including none as of now and a pg_dump switch that you can repeat to include whichever extension you wish to. The effect is to transport the files and install them in the expected place on the target server where you restore. And now we really process all extensions the same and you can update inline an extension that you installed the 9.1 way, and vice versa. Don't let me speak about extension distribution facilities just now :) Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: