Re: Extensions Dependency Checking - Mailing list pgsql-hackers

From Aidan Van Dyk
Subject Re: Extensions Dependency Checking
Date
Msg-id BANLkTimn1z31QqOgV-fRi89j0atYpL+k7Q@mail.gmail.com
Whole thread Raw
In response to Re: Extensions Dependency Checking  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: Extensions Dependency Checking
List pgsql-hackers
On Tue, Apr 5, 2011 at 4:20 PM, David E. Wheeler <david@kineticode.com> wrote:
> On Apr 4, 2011, at 3:57 PM, Tom Lane wrote:
>
>>> I think the general movement is toward *feature* dependancies.  So for
>>> intstance, an extension can specify what *feature* it requires, and
>>> difference "versions" of an extension can provide different
>>> "features".
>>
>> Right.
>
> Sounds like a book-keeping nightmare for extension developers. It will discourage large or rapidly-evolving
extensionslike pgTAP because it will be a PITA to specify features. 

Sure, but if you want, the "feature" you can provide can be something like:  pgtap-1.0 (or any of
pgtap-0.2{0,1,2,3,4}).

And if your package is backwards compatable, it could even provide:  pgtap-0.25  pgtap-0.24  pgtap-0.23

And that also means that you don't have to screw every body over when
some future pgtap-123.45 is no longer compatible, and the extensions
have relied on "$VERSION > 0.23" meaning they'll work with it.

I mean, PG itself is an example.  Does pg > 8.4 mean your code will
work with all future (or even past, but > 8.4) PG versions?

>> We're not there yet, and we're not going to get there in time for 9.1.
>> But in any case, mechanisms that involve version ordering comparisons
>> seem to be on their way out for deciding whether package A is
>> compatible with package B.
>
> This is news to me, frankly, and the bookkeeping requirements seem potentially awful.
>
> If it's possible that it won't work out this way, that those arguing for version dependency resolution end up getting
theconsensus, not having a version string format is going to be a nightmare. On the other hand, if we added one now,
andfeature dependency tracking won the day, well, a version string format could always be loosened later. 

As someone who has had to try and deal with "package versions" for
dependencies in RPM and DEB, and been through the hell that is open
source package variants, all with the ability to turn on/off features
at configure/compile time, a just versions even with  <, <=, =, >=, >
all mapped correctly isn't good enough.

Of course, I'ld love for extension in 9.1 to provide a basic
provides/features for my extension to give, but if that train has
already left the station, I don't have much choice ;-(

a.

--
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Extensions Dependency Checking
Next
From: Peter Eisentraut
Date:
Subject: Re: WIP: Allow SQL-language functions to reference parameters by parameter name