Re: More extension issues: ownership and search_path

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: More extension issues: ownership and search_path
Date: 2011-02-07 18:58:30
Message-ID: m2oc6nvfhl.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> On reflection, the set of extensions that an extension depends on is
> obviously a property of the extension, which means it ought to be
> specified in the extension's control file, not in the CREATE EXTENSION
> command. So now I'm thinking something like
>
> requires = 'foo, bar, baz'

+1

And that can change at upgrade time, of course, but that's another
story. Ditto for recommends and conflict dependency types, that's
material for 9.2 at best.

> in the file. We could even imagine autoloading such dependencies if
> they're not already installed, but that's a frammish for later. (One
> objection to autoloading is it's not clear which schema to drop the
> other extensions into.)

Well I don't see why it wouldn't be the same schema in case of auto
solving dependencies, but I don't see a pressing need to have automatic
dependency following at install time (we're still in the realm of dpkg,
we'll get into apt-get next) :)

That said, we should do something about ALTER EXTENSION SET SCHEMA and
the relocatable property. I'm thinking that an extension stops being
relocatable as soon as any of its reverse dependencies (all the tree) is
not relocatable.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Cédric Villemain 2011-02-07 19:02:54 Re: limiting hint bit I/O
Previous Message Kevin Grittner 2011-02-07 18:38:34 Re: Spread checkpoint sync