Robert Haas <robertmhaas@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