On Wed, Dec 8, 2010 at 12:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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.fsf@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