Thread

  1. Satisfy extension dependency by one of multiple extensions

    Yeb Havinga <yebhavinga@gmail.com> — 2011-09-23T11:56:36Z

    Hello list,
    
    I have a use case where an extension dependency can be satisfied by one 
    of five other extensions. Currently I'm unable to express that in the 
    extension control file, since the elements from 'requires' are currently 
    searched on exact name match. The attached patch changes this behaviour 
    for list elements that end with a *, into prefix matching, so that e.g. 
    table* matches tablefunc.
    
    This allows me to specify in a controlfile
    
    requires 'vocab*'
    
    which is satisfied by having either one of the following extensions loaded:
    
    vocab2005
    vocab2006
    vocab2008
    vocab2009
    vocab2010
    
    thoughts?
    
    regards,
    Yeb Havinga
    
    -- 
    Yeb Havinga
    http://www.mgrid.net/
    Mastering Medical Data
    
    
  2. Re: Satisfy extension dependency by one of multiple extensions

    Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> — 2011-09-23T12:19:34Z

    On 23.09.2011 14:56, Yeb Havinga wrote:
    > I have a use case where an extension dependency can be satisfied by one
    > of five other extensions. Currently I'm unable to express that in the
    > extension control file, since the elements from 'requires' are currently
    > searched on exact name match. The attached patch changes this behaviour
    > for list elements that end with a *, into prefix matching, so that e.g.
    > table* matches tablefunc.
    
    That's going to quickly extend into even more complex rules, like "foo 
    OR bar", "(foo OR bar) AND (foobar)" etc. IIRC the extension control 
    file format was modeled after some other package management system (.deb 
    ?). You might want to look at the past discussions when the extension 
    control file format was decided.
    
    We might want to have a system where an extension can declare that it 
    "provides" capabilites, and then have another extension "require" those 
    capabilities. That would be a neater solution to the case that there are 
    multiple extensions that all provide the same capability.
    
    -- 
       Heikki Linnakangas
       EnterpriseDB   http://www.enterprisedb.com
    
    
  3. Re: Satisfy extension dependency by one of multiple extensions

    Yeb Havinga <yebhavinga@gmail.com> — 2011-09-23T13:30:55Z

    On 2011-09-23 14:19, Heikki Linnakangas wrote:
    > On 23.09.2011 14:56, Yeb Havinga wrote:
    >> I have a use case where an extension dependency can be satisfied by one
    >> of five other extensions. Currently I'm unable to express that in the
    >> extension control file, since the elements from 'requires' are currently
    >> searched on exact name match. The attached patch changes this behaviour
    >> for list elements that end with a *, into prefix matching, so that e.g.
    >> table* matches tablefunc.
    >
    > That's going to quickly extend into even more complex rules, like "foo 
    > OR bar", "(foo OR bar) AND (foobar)" etc. IIRC the extension control 
    > file format was modeled after some other package management system 
    > (.deb ?). You might want to look at the past discussions when the 
    > extension control file format was decided.
    
    Ech.. 2364 hits on 'extension' in my mailbox. However I found a thread 
    'extension dependency checking' that also talks about version numbers 
    and the 'provides' capability you mention below.
    >
    > We might want to have a system where an extension can declare that it 
    > "provides" capabilites, and then have another extension "require" 
    > those capabilities. That would be a neater solution to the case that 
    > there are multiple extensions that all provide the same capability.
    >
    
    Yes that would be neater. I can't think of anything else however than to 
    add 'extprovides' to pg_extension, fill it with an explicit 'provides' 
    from the control file when present, or extname otherwise, and use that 
    column to check the 'requires' list on extension creation time.
    
    -- 
    Yeb Havinga
    http://www.mgrid.net/
    Mastering Medical Data
    
    
    
  4. Re: Satisfy extension dependency by one of multiple extensions

    Dimitri Fontaine <dimitri@2ndquadrant.fr> — 2011-09-24T19:15:25Z

    Yeb Havinga <yebhavinga@gmail.com> writes:
    >> We might want to have a system where an extension can declare that it
    >> "provides" capabilites, and then have another extension "require" those
    >> capabilities. That would be a neater solution to the case that there are
    >> multiple extensions that all provide the same capability.
    
    +1
    
    > Yes that would be neater. I can't think of anything else however than to add
    > extprovides' to pg_extension, fill it with an explicit 'provides' from the
    > control file when present, or extname otherwise, and use that column to
    > check the 'requires' list on extension creation time.
    
    That sounds like a good rough plan.
    
    Then we need to think about maintenance down the road, some releases
    from now we will need more features around the same topic.  Debian
    control file also has Conflicts and Replaces entries, so that using the
    three of them you can handle a smooth upgrade even when the extension
    changed its name or has been superseded by a new one which often has the
    advantage of being maintained.
    
    Regards,
    -- 
    Dimitri Fontaine
    http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support
    
    
  5. Re: Satisfy extension dependency by one of multiple extensions

    Josh Berkus <josh@agliodbs.com> — 2011-09-24T21:01:00Z

    All,
    
    > >> We might want to have a system where an extension can declare that
    > >> it
    > >> "provides" capabilites, and then have another extension "require"
    > >> those
    > >> capabilities. That would be a neater solution to the case that
    > >> there are
    > >> multiple extensions that all provide the same capability.
    > 
    > +1
    
    As a warning, this is the sort of thing which DEB and RPM have spent years implementing ... and still have problems with.  Not that we shouldn't do it, but we should be prepared for the amount of troubleshooting involved, which will be considerable.
    
    --Josh Berkus