Tom Lane <tgl@sss.pgh.pa.us> writes:
> I thought I already pointed that out, but: we have *extensions*. What
> we don't have is a convenient method of dealing with functions that need
> to be migrated across extensions, or from an extension to core, between
> one major release and the next. It would clearly be nice to have that
> someday, but we don't have it now. Designing on the assumption that 9.3
Well, my patch for 9.2 called "Finer Extension Dependencies" was all
about supporting that. The idea is to be able to name a set of functions
(or other objects) then setup a dependency graph towards that arbitrary
name. Then it's possible to migrate that named set of objects from an
extension to another one, and it's possible for core to publish a list
of provided names of set of objects provided.
https://commitfest.postgresql.org/action/patch_view?id=727
Inspiring my work from some other development facilities I enjoy
spending my time with, I called that set a "feature" and added ways for
extensions to "provide" and "require" them, like has been done in some
lisps for more than 3 decades now. I'm not wedded to those terms, which
have been bringing confusion on the table before, please suggest some
other ones if you think you like the feature.
I'm going to have this patch in the next CF so that we can talk about it
again, as I think it is actually designed to help us fix the problem
here.
The only missing part in the patch is allowing for the "core" to declare
a set of set of objects (a set of features in its current terminology)
that it brings on the table. Such a list already exists though, and is
using the same terminology as in my patch:
http://www.postgresql.org/docs/9.2/static/features-sql-standard.html
We wouldn't only publish the standard compliant feature list with such a
mechanism though or it would be quite useless for our operations here.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
