Re: ALTER EXTENSION UPGRADE, v3

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.

> 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.

> case. The real issue is what happens when you want to install
> extension A, which depends on extensions B, C, and D, and B, C, and D
> are all in non-standard locations. Does that have any chance of
> working under the system we're proposing?

Yes. It all depends on what's in the extension and what exactly the
dependency is. You have more problem when calling another extension's
function relying on the search_path that you have when using another
extension's data type. But it boils down to which way the dependency is
setup. And if moving objects breaks the install, you move them back
then fill a bug, and the extension's author changes relocatable to false
in the next version, or fix the bug in another way.

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