Re: Extensions Dependency Checking

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Aidan Van Dyk <aidan(at)highrise(dot)ca>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, "pgsql-hackers\(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extensions Dependency Checking
Date: 2011-04-05 13:30:39
Message-ID: 87sjtwvn9c.fsf@hi-media-techno.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
> 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".

That sounds like what Emacs is doing too.

> But checking http://developer.postgresql.org/pgdocs/postgres/extend-extensions.html,
> I don't see any "provides" mechanism. That might be something
> actually needed if we are trying to avoid "version" comparisons and
> want to be describing actual dependencies...

The 'provides' mechanism can be added later I think. It's like saying
that in 9.1 an extension 'foo' provides the feature 'foo' and you can't
control that, whereas in future version you will be able to control what
your extension (and its specific version) provides.

Also we will be able to list what the PostgreSQL server provides, maybe,
so that compile time options can be depended on by extensions.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-04-05 13:37:51 Re: cast from integer to money
Previous Message Luca Ferrari 2011-04-05 13:30:10 Re: 9.0.3 SIGFAULT on FreeBSD with dtrace