Re: More extension issues: ownership and search_path - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: More extension issues: ownership and search_path
Date
Msg-id m2k4hbtxlt.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: More extension issues: ownership and search_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: More extension issues: ownership and search_path  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.

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@.  Moving the dependencies underneath it in this case looks
to me more than a risk: we know we're breaking things.

What you're saying (or what I'm reading at least) is that if
earthdistance is relocatable, you don't have faith that it means we can
actually move cube without collateral damages.  Well, the author said it
would cope fine, and in this case I see no reason not to believe him.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: SQL/MED - file_fdw
Next
From: "Kevin Grittner"
Date:
Subject: Re: Sync Rep for 2011CF1