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. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
