From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
Cc: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Finer Extension dependencies |
Date: | 2012-03-23 18:28:30 |
Message-ID: | 1332527045-sup-3486@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Dimitri Fontaine's message of vie mar 23 13:12:22 -0300 2012:
>
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Why do features have OIDs? Is this for pg_depend entries? If so, would
> > it work to have pg_depend entries point to extensions instead?
>
> Yes, for pg_depend, no I don't know how to make that work with pointing
> to the extensions directly, because the whole point here is to be able
> to depend on a feature rather than the whole extension.
Yes, I understand that -- but would it work to have the feature
resolution be done at install/upgrade time, and once it's resolved, you
record it by storing the extension than contains the feature? That way
it correctly breaks when the extension gets removed; and since we ensure
that upgrading an extension means delete its features and then insert
them anew, it would also correctly break at that point if some feature
is no longer provided.
I'm not wedded to this idea, so if we think it doesn't work for some
reason, I have no problem going back to the idea of having direct
dependencies to features instead. But I think it's worth considering.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2012-03-23 18:38:56 | Re: CREATE FOREGIN TABLE LACUNA |
Previous Message | Merlin Moncure | 2012-03-23 18:08:54 | Re: query cache |