On Tue, Apr 5, 2011 at 4:51 PM, David E. Wheeler <da...@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 it for 9.2.
>
> Anyway, your post helps me to understand things better, and so I'm less 
> insistent about imposing a version numbering scheme now (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,
ai...@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

-- 
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