Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> If you're worried about that, then it's questionable whether ALTER
>> EXTENSION SET SCHEMA makes sense at all, ever. I don't see any reason
>> to think that an extension is more fragile for this purpose than any
>> other random SQL dependencies. Also, an extension being relocatable
>> doesn't seem to me to guarantee that it can cope with its dependencies
>> moving around; they're really independent properties.
> Well a relocatable extension certainly supports SET SCHEMA just fine, or
> it would not have the property. Then your conclusion is right. My
> comment was about what happens when things are setup the other way.
Yes, I understood that.
> We have earthdistance that depends on cube. Let's pretend that
> earthdistance is not relocatable. I think we should then consider (when
> both are installed) that cube is not relocatable, whatever its control
> file says. That's because not relocatable means that the install script
> is using the @extschema@ place holder and the fragility there is known
> quite high: the install script and some installed objects do depend on
> @extschema@.
But @extschema@ isn't affected by where the other modules are.
The basic issue here is that we might have wired something about the
referenced schemas into one of the objects in the dependent extension,
for example via
create function foo() ... SET search_path FROM CURRENT;
I agree that this is a risk. My point is that you can do that without
any extension, and you're just as much at risk. If you think that this
is something we must protect against, I think ripping out ALTER
EXTENSION SET SCHEMA altogether is the only real answer. I see no
argument whatsoever why we should lock down extensions and only extensions
against this risk.
regards, tom lane