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
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 |