Re: Extensions Dependency Checking - Mailing list pgsql-hackers

From Aidan Van Dyk
Subject Re: Extensions Dependency Checking
Date
Msg-id BANLkTimC9t3bvNSOsP-+wR6+JwnCH3d+TQ@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:51 PM, David E. Wheeler <david@kineticode.com> wrote:

>> 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 ;-(
>
> Yeah, but the way it is doesn't break the ability to do it later. I suspect that Dim and Tom will be thinking about
itfor 9.2. 
>
> Anyway, your post helps me to understand things better, and so I'm less insistent about imposing a version numbering
schemenow (though I still think it would be more useful to have one than not). 

Versions are useful for figuring out if I should upgrade packages or
not.  But I believe the extension framework has explicitly made the
"upgrade" problem a manual one at this point, either taking
destination versions from the control, or the alter command.

So for PGXN's problem, I see the point of versions being required.
But for installation the dependancy graph, "provides/features" rather
than versions are much more useful.    And automatic feature/provides
(like library so, and symbol versions in the OS package world,
"objects" in PG world) would definitely be nice, but my Makefile can
build those for me for now until 9.2 (or 9.3, 9.3, etc), if only I had
a way to track them with my installed extension ;-) </stop begging>

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: [DOCS] Uppercase SGML entity declarations