Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
