Tom Lane <t...@sss.pgh.pa.us> writes: > Dimitri's last reply to me > http://archives.postgresql.org/message-id/87r5ds1v4q....@hi-media-techno.com > suggests that what he has in mind is to define a relocatable extension > as one that can be relocated ;-), ie it does not contain any such > gotchas. Maybe this is too ugly in itself, or not useful enough to be > worth doing. But it doesn't seem technically unworkable to me, so long > as relocatability is made an explicitly declared property of extensions.
Well it does not seem to be complex to code. It's about having a new property in the control file, relocatable, boolean. This property is required and controls the behavior of the CREATE EXTENSION ... WITH SCHEMA command. When true we use the ALTER EXTENSION SET SCHEMA code path and when false, the placeholder replacement code path. The ALTER command has already been developed so I need to merge it into the main patch. The ALTER EXTENSION SET SCHEMA command needs to be adapted so that it checks that all the extension's objects are currently in the same schema and error out if that's not the case. I'm not going be able to deliver a new patch including that and the other changes required by David Wheeler's review by tonight, but by Friday's evening seems like a reasonable target. > It's certainly true that a large fraction of contrib modules should be > relocatable in that sense, because they just contain C functions that > aren't going to care. As they all currently are using the SET search_path TO public; trick, I think they are all relocatable as is and all I need is to remove that line (and add the property to the control file). > Or are you complaining that somebody could break relocatability after > the fact by altering the contained objects? Sure, but he could break > the extension in any number of other ways as well by making such > alterations. The answer to that is privilege checks, and superusers > being presumed to know what they're doing. +1 Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
