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 extensions like pgTAP because it will be a 
PITA to specify features.

>> But checking 
>> http://developer.postgresql.org/pgdocs/postgres/extend-extensions.html,
>> I don't see any "provides" mechanism.
> 
> Yes, some sort of manual Provides: (in addition to automatically
> extracted Provides:) would likely be part of any serious solution.

<shed type="bike">I'd like to request "Features:" instead of "Provides:".</shed>

> 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 the consensus, not having a 
version string format is going to be a nightmare. On the other hand, if we 
added one now, and feature dependency tracking won the day, well, a version 
string format could always be loosened later.

Best,

David


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to