Re: Finer Extension dependencies - Mailing list pgsql-hackers

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.

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

It also allows to track at update time when the feature set changes if
we're removing a feature that some other installed extension is
depending on, allowing our users to know that they should either drop
this other extension or update it too.

> 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? :)

> - How does pg_upgrade interact with this? The dependency changes.

We're compatible because the extension name itself is always considered
as a feature and added to the catalogs, so that e.g. require = 'cube'
will now target a feature rather than an extension, and this feature
defaults to being provided by the 'create extension cube' statement that
pg_upgrade issues given 9.1 dependency tracking.

> A minor memo.
> list_extension_features(): I guess the size argument for repalloc is
> bogus.

Oh, a quick review of repalloc call points seems to indicate you're
right, I'll fix that in the next version of the patch.

> So, that's pretty much I've reviewed quickly. I'll need more time to
> look in detail, but I'd like more inputs for the high-level design and
> direction.

I hope to be answering to your questions here, please ask for more
details as you need them!

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