Re: Quick Extensions Question

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Quick Extensions Question
Date: 2011-03-03 17:56:30
Message-ID: 084BA9F9-42C1-4D59-B519-096D9195F91B@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mar 3, 2011, at 9:47 AM, Dimitri Fontaine wrote:

> Then, what about a control file property to cover that?
>
> pl_language = plpgsql
>
> Then when running the script any object attached to the extension that
> is not a 'pg_catalog.pg_language'::regclass is an ERROR. And only when
> the pl_language property is used then the superuser-only check is
> bypassed.

More simply, I think there are two kinds of dependencies:

* Other extensions
* Core features

Notwithstanding that PLs might be extensions, now or in the future, the necessity to require other stuff from core, like libxml support or SSL, together with your example, leads me to think that we ought to think about having two ways of specifying dependencies: requires and core_requires. The latter might look something like:

core_requires = plpgsql libxml

The downside of course is that then there would need to be a second infrastructure for tracking core dependencies, and it would need to be kept up-to-date. But I think something like this will be essential -- even if it only supports core PLs for now.

Best,

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2011-03-03 17:57:35 Re: Quick Extensions Question
Previous Message Dimitri Fontaine 2011-03-03 17:55:51 Re: Quick Extensions Question