Re: pg_execute_from_file review

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

In response to

Responses

Browse pgsql-hackers by date

  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.