Re: Finer Extension dependencies - Mailing list pgsql-hackers

On Thu, Mar 29, 2012 at 2:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yeah.  AFAIK, nobody actually does that.  In my experience with Red Hat
> packages, so-called "virtual Provides" (which are exactly equivalent to
> this proposed feature) are used only for cases where there is or is
> planned to be more than one package that can supply a given API, and the
> Provides is really more of a logical package name than an identifier of
> a feature as such.

Note that this feature as designed will NOT service that use-case, as
discussed upthread, and in fact it would probably need a full rewrite
to do so, because the principle of operation is based on the
dependency mechanism, which doesn't support this.  In fact, ALTER
EXTENSION .. UPDATE as implemented in this patch is already doing some
clever tomfoolery to make things work as the user will expect - when
you update an extension, it removes the dependencies between the
extension and its extension features, then drops any extension
features that are no longer needed, then puts back the dependencies.
This produces pretty logical error messages, but I don't think it
generalizes to any of the other things we might want to do (e.g.
version number dependencies) so while we could commit this patch the
way it is now I think doing anything more complex will require a
different approach.

> When people want to depend on a feature that was
> added after initial release of a package, they invariably use
> versioned dependencies like "Requires: foobar >= nnn".  And it's also
> pretty common to use such a dependency because you need to have a bug
> fixed that was fixed in version nnn; so assuming that you only need
> feature names for, er, features may be a mistake too.

Hmm, interesting.

> So if you look at common practice, this whole idea is wrong and we ought
> to define a way to compare version numbers instead.  I'm not entirely
> sure that I want to go there yet, but it certainly bears considering as
> a time-tested alternative design.

I think that's definitely worth considering.  One idea would be to
mandate that you can only use the version-dependencies feature if both
versions are of some specific form (e.g. two or three integers
separated by periods).  If you try to depend on foo >= 1.b or if you
depend on foo >= 1.3 but the installed version is 1.b, it errors out.

Frankly, I'm not sure we bet on the right horse in not mandating a
version numbering scheme from the beginning.  But given that we
didn't, we probably don't want to get too forceful about it too
quickly.  However, we could ease into it by documenting a recommended
numbering scheme and making features like version-dependencies work
only when that scheme is used.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company