On Wed, Dec 8, 2010 at 12:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> It's also worth noting that ALTER EXTENSION .. SET SCHEMA does NOT >> guarantee a correct relocation, because someone might have done ALTER >> FUNCTION .. SET search_path = @extschema@, and that's not going to get >> properly fixed up. I'm coming to the conclusion more and more that >> ALTER EXTENSION .. SET SCHEMA just can't work reliably. > > 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. > 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.
I don't find that a very satisfying solution, but I guess we could do it that way. > 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. I wasn't complaining about this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
