Robert Haas <robertmh...@gmail.com> writes: > I think you've gotten to the heart of the matter here. Extensions > need to either be schema objects, or not. If they are, let's go all > the way and compel everything in the extension to live in the schema > that owns it, and make the extension itself live in that schema too. > You can even imagine two different users, each with their own schema, > installing the same extension with different settings or something > (pay no attention to the man waving his hands). On the other hand, if > they're NOT schema objects, then ALTER EXTENSION .. SET SCHEMA Is not > well-defined and we should reject that portion of this effort. Being > half-way in the middle doesn't seem like a good idea.
I confess to not having paid a whole lot of attention to the threads about this feature, so maybe this point has been addressed already, but: what of the schema itself? That is, if an extension has some/all of its objects in a given schema, is that schema itself one of the objects created/owned by the extension, or not? I can imagine use-cases for both ways, but it seems like which of these models you choose is a pretty critical aspect of how you envision all this. In particular I wonder whether directly renaming an owned schema would cover the use-cases for ALTER EXTENSION .. SET SCHEMA. OTOH, this isn't going to help for what I suspect is the *real* motivating use-case, namely "I dumped all my extensions into schema public and now I've thought better of it". If you dumped an extension into public it clearly can't own that. Anyway, in a less blue-sky vein: we could fix some of these problems by having an explicit relocatable-or-not property for extensions. If it is relocatable, it's required to keep all its owned objects in the target schema, and ALTER EXTENSION .. SET SCHEMA is allowed; else not. This does nothing for the fix-the-search_path-property problem, though. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers