Re: ALTER EXTENSION UPGRADE, v3

On Thu, Feb 10, 2011 at 3:33 PM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> Now, if you want to argue that moving an extension after the fact (ALTER
>>> EXTENSION SET SCHEMA) is so dangerous as to be useless, I wouldn't
>>> argue very hard.  Do you want to propose ripping that out?  But
>>> relocating at first install doesn't seem horrible.
>
> Either an extension is relocatable or you have to deal with what Josh
> Berkus the search_path hell.  Lots of databases are using a host of
> schema for their own objects already, and will want to have extensions
> either all in the same place or scattered around each in its own schema.
>
> I don't think we are in a position to impose a choice to our users here.

Well, for that matter, the user could want to install the same SQL
objects in more than one schema, in effect installing the same
extension twice.

>> I'm not very concerned about letting people set the schema after the
>> fact.  If we think it's OK for them to whack the location around at
>> first install, I don't know why we shouldn't also let them whack it
>> around later.  The question I have is whether it's really reasonable
>> to let extension-owned objects be moved around at all.  It'll probably
>> work fine as long as there are no other extensions depending on the
>> one that's getting moved, but it doesn't pay to design for the trivial
>
> If your extension depends on some others and your scripts are not
> prepared to deal with those being moved around, you just setup your
> extension as not relocatable.  That's it.

No, you have to get *those other module authors* to make *their*
extensions not relocatable so that you can depend on them.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company