Re: Finer Extension dependencies - Mailing list pgsql-hackers

On Thu, Mar 22, 2012 at 2:08 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> get_available_versions_for_extension seems to contain a bunch of
>> commented-out lines ...
>
> Damn. Sorry about that.  Here's a cleaned-up version of the patch.

I'm not completely convinced that the case has been made that this is
a useful thing to have.  It is true that systems like RPM have (and
need) something like this, but that doesn't seem like a sufficient
argument.  The difference is that any set of RPMs which is designed to
be used as a set has been packaged by a single project which
(hopefully) has a consistent set of policies for how things are tagged
and labeled and has done some integration testing to makes sure that
every package which provides the wumpus feature actually is sufficient
for the needs of all packages that depend on wumpus.  On the other
hand, PostgreSQL extensions are a free-for-all.  Anybody can publish
an extension on PGXN (or elsewhere), and they can stuff whatever junk
they want in their control file - or more likely, fail to stuff
anything in there at all, so that a package author who might want to
depend on feature X may well find that not all the packages that
provide feature X are tagged as providing it.  If that turns out to be
the case, are they going to (a) contact all of those package authors
and convince them to update their control files or (b) punt?  I'll bet
on (b).

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
way to send mail.  Fine.  But, what exactly is that way?  It
presumably involves calling a function.  It is very likely that if
there are multiple mail-sending extension packages for PostgreSQL,
they don't all create a function with exactly the same name and
signature.  Even if they did, the extension that is depending on this
functionality has no way of knowing what schema that function is going
to be in, unless all of those extensions are not-relocatable, which I
think extension authors will be reluctant to do for entirely valid
reasons.  Now, the extension author can hack around all this by
writing code (in PL/pgsql, for example) to search through the system
catalogs and figure out which extension is providing the smtp feature
and in what schema it's located; and then, having done that, they can
even deduce the function name and signature, build a dynamically
generated SQL query, and send mail.  Woohoo!

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.

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

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