Re: Finer Extension dependencies

On Wed, Mar 28, 2012 at 8:52 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Mar 28, 2012 at 11:28 AM, Dimitri Fontaine
> <dimitri(at)2ndquadrant(dot)fr> wrote:
>>> 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.
>
> Based on this information, it seems that I've misinterpreted the
> purpose of the patch.  Since extension features seem to live in a
> global namespace, I assumed that the purpose of the patch was to allow
> both extension A and extension B to provide feature F, and extension C
> to depend on F rather than A or B specifically.  What I understand you
> to be saying here is that's not really what you're trying to
> accomplish.  Instead, you're just concerned about allowing some but
> not all versions of package A to provide feature F, so that other
> extensions can depend on F to get the specific version of A that they
> need (and not, as I had assumed, so that they can get either A or B).
>
> Let me think more about that.  Maybe I'm just easily confused here, or
> maybe there is something that should be changed in the code or docs;
> I'm not sure yet.
>
> On a more prosaic note, you seem to have made a mistake when
> generating the v5 diff.  It includes reverts of a couple of unrelated,
> recent patches.
>
>> WTF? WTF?
>
> On a further note, I have spent a heck of a lot more time reviewing
> other people's patches this CommitFest than you have, and I don't
> appreciate this.  If you'd rather that I didn't spend time on this
> patch, I have plenty of other things to do with my time.
>

Frankly I'm still against this patch. Since I started to review it
I've never been convinced with the use case. Yeah, someone said it'd
be useful to him, but as a developer of some of PGXN modules I don't
see it. I totally agree with Robert's point that one feature is not
standardized and nobody can tell how you can depend on the feature in
the end. Mind you, I've never heard about building dependency by its
name as a string in other packaging system. If you want to introduce
the concept of version dependency not feature name dependency, do
*it*; I don't think feature dependency solves it.

I know you Dimitri is working so hard for this and other patches, but
it seems to me that the quality of both of the design and patch code
are not adequate at this point of time. I think I agree we are not
100% happy with the current dependency system of extensions, but we
need more time to think and make it mature idea rather than rushing
and pushing and dropping something premature. The cost we would pay
if we rushed this to this release will be higher than what we'd get
from it, I think.

Thanks,
--
Hitoshi Harada