Re: Finer Extension dependencies - Mailing list pgsql-hackers

On Sat, Jan 21, 2012 at 9:20 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Hi,
>
> Thank you for reviewing this patch!
>
> Hitoshi Harada <umi.tanuki@gmail.com> writes:
>> The patch applies with one reject, which I could fix easily. The make
>> check passed.
>
> Bitrot happens fast in this season…  will produce another version of the
> patch.
>
>> Table "pg_catalog.pg_extension_feature"
>>    Column   | Type | Modifiers
>> ------------+------+-----------
>>  extoid     | oid  | not null
>>  extfeature | name | not null
>> Indexes:
>>     "pg_extension_feature_index" UNIQUE, btree (extoid, extfeature)
>>     "pg_extension_feature_oid_index" UNIQUE, btree (oid)
>>
>> * I'm not quit sure why pg_extension_feature_index needs extoid column.
>
> That allows managing features per extension: you need to know which
> extension is providing which feature to be able to solve dependencies.

Do you mean you want UNIQUE constraint by this index? I found the
usage is to search feature by (only) its name, so I wondered if extoid
is not necessary.

>> * I have a big question to add two-column catalog. I don't mind the
>> actual number of columns, but if the table has only two columns, it
>> implies the design may be bad. Only two column catalog other than this
>> is pg_largeobject_metadata.
>
> We need each feature to be a full PostgreSQL object so that we can use
> the dependency tracking.  That allows to manage DROP EXTENSION foo and
> cascade to extensions that depend on feature(s) provided by foo.

I guess if we spend more time, we'll figure out what is "feature"
actually, and then will see what kind of columns/attributes are needed
to represent it. Although I agree we can add them later, again, this
may imply the design is premature. (it's ok if i am the only person
who thinks so)

>> Next, some questions:
>> - Why is the finer dependency needed? Do you have tangible example
>> that struggles with the dependency granularity? I feel so good about
>> the existing dependency on extension as an extension developer of
>> several ones.
>
> The problem is not yet very apparent only because extensions are very
> new. The main thing we address with this patch is depending on a feature
> that appeared while developing an extension or that gets removed down
> the line. It allows to depend on features and avoid needing to compare
> version numbers and maintain a list of which version number is providing
> which feature.
>
> This feature has been asked by several extension users, beginning even
> before 9.1 got released.
>
>> - What happens if DROP EXTENSION ... CASCADE? Does it work?
>
> It should, what happens when you try? :)

I just tried DROP EXTENSION now, and found it broken :(

db1=# create extension kmeans;
CREATE EXTENSION
db1=# drop extension kmeans;
ERROR:  cannot drop extension kmeans because extension feature kmeans
requires it
HINT:  You can drop extension feature kmeans instead.
db1=# drop extension kmeans cascade;
ERROR:  cannot drop extension kmeans because extension feature kmeans
requires it
HINT:  You can drop extension feature kmeans instead.

Am I missing something? I'm confused why this happens.


Thanks,
--
Hitoshi Harada