On Tue, Dec 7, 2010 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Anyway the main problem at the moment is that the proposed design is
> meant to allow "relocatable" extensions, but it doesn't behave
> pleasantly in the case where somebody tries to relocate a
> non-relocatable extension.
>
> It also strikes me that the plan appears to be to support ALTER
> EXTENSION SET SCHEMA to relocate an extension after the fact, but this
> will absolutely *not* work with the available infrastructure. Remember
> that example of a SQL function with a SET search_path = @extschema@
> option? There's no way to fix that up, nor any other case where the
> schema was substituted into an object declaration. So I'm back to
> thinking that the textual-substitution idea is fundamentally deficient.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
