Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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
Well both cases are supported. If the extension's script issue the
CREATE SCHEMA command, then we track the dependency, but the script is
free to create its objects into whatever already existing schema.
Some extensions you want separated, and some you want to put them all in
the same schema, that's the documentation example using "utils" here.
> 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.
Exactly.
> 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.
The search_path is the complex (as in AI complete) part of it, but given
your idea here, we could make it so that only the non-relocatable
extensions benefit from the @extschema@ placeholder.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr