Re: Extensions Dependency Checking
От | Aidan Van Dyk |
---|---|
Тема | Re: Extensions Dependency Checking |
Дата | |
Msg-id | BANLkTimC9t3bvNSOsP-+wR6+JwnCH3d+TQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Extensions Dependency Checking ("David E. Wheeler" <david@kineticode.com>) |
Ответы |
Re: Extensions Dependency Checking
|
Список | 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 по дате отправления: