From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Joshua Tolley <eggyknap(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_execute_from_file review |
Date: | 2010-12-07 17:46:27 |
Message-ID: | AANLkTim+yZg1bdwokxct6tVKoaFXCPFw1TWtkc7Pv=Ga@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 7, 2010 at 11:38 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Rijkers | 2010-12-07 17:53:49 | Re: Fwd: new patch of MERGE (merge_204) & a question about duplicated ctid |
Previous Message | Tom Lane | 2010-12-07 17:37:08 | Re: Feature request - CREATE TYPE ... WITH OID = oid_number. |