Re: Finer Extension dependencies

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I'm not completely convinced that the case has been made that this is
> a useful thing to have.

You're basically saying that the current lack of extension distribution
is a good reason for not building the tools allowing to create said
distribution. WTF?

(PGXN uses the word distribution with yet another meaning, not to be
mistaken for the kind of work done by debian or fedora teams)

> Even if we suppose that the above is not a problem, it seems to me
> that there's a further difficulty. What exactly does it mean to
> provide a feature like "smtp"? Presumably, it means that you have a

Now you're saying that you want another feature built on top of this
one, which is the ability to normalize features so that each provider is
following up on the same standard as soon as they happen to provide the
same feature.

Then you say that having a features mechanism without the whole policy
and standardisation and normalisation is not going to fly. WTF?

> In practice, however, that sounds like a real pain in the neck. I
> would expect most people who were packaging extensions to handle a
> situation like this by forcing the user to provide the name of the
> function to be called, either via a control table or via a GUC. And
> once you've done that, it makes no sense to shove a feature dependency
> into the extension, because the user might very well just write an
> appropriate function themselves and tell the extension to call that.

I don't know what you're talking about here, all I can say is that is
has nothing to do with what the patch is implementing.

What's in the patch is a way to depend on known versions of an extension
rather than the extension wholesale, whatever the version. Using feature
dependency allow to avoid 2 particularly messy things:

- imposing a version numbering scheme with a comparator
- maintaining a separate feature matrix

So instead of having to say "foo version 1.2 is now doing buzz"
and having an extension depend on foo >= 1.2, you can say that your
extension depends on the buzz feature. That's about it.

> Theory aside, I am, like Alvaro, a bit skeptical of making extension
> features their own first-class objects. I think that part of the
> point of this mechanism in other package management systems is to
> allow a user to execute an RPM (say) transaction that drops an
> extension which provides feature X but makes up for it by installing,
> in the same transaction, a new extension that provides the same
> feature X. I suspect that this won't work with the design you have

As far as I know, RPM and deb and other popular packaging systems are
imposing mutually incompatible version number policies and tools to
compare them, and then packagers have to manually care about translating
a feature matrix into version number CHECK clauses.

The require/provide facility is something more spread into Emacs Lisp
and Common Lisp, if you really need to see it in action someplace else.

But again, really, it's all about being able to have an extension depend
on « the new hstore » or « the new pg_stat_statement ». That's it.

About having a new catalog to host extension features, the problems I'm
trying to solve with that are about extension upgrade. You can add new
features at upgrade, you can also drop some. I don't know how to tell
the user that extension X has to be removed to upgrade foo to 1.3 where
it's not providing feature "buzz" anymore, without pg_extension_feature.

> right now. In fact, I suspect it also won't work to install the new
> extension first and then drop the old one; I might be wrong, but I
> don't think our dependency mechanism has any support for depending on
> either A or B, which is really what is needed here.

We have ALTER EXTENSION foo UPDATE, you know.

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