This issue is a very old issue and people have not come up with the definitive solution to distributing "datablades" as Stonebraker called them. For now, the best way is to have small well managed projects on PgFoundry and encourage people to review what is available there. Maybe we can even make perusing the projects there easier. As people build smaller projects on pgfoundry is would be ideal to have "blessed" projects where "blessing" means adhered to an installation procedure. There is already a standard way to add things into the contrib line (but I'm blanking on the name xpg?). All addons require some SQL and most add-ons only require SQL. But those that require C should adhere to the xpg (?) standard. Those that require other languages installed should have the mechanisms built in to at minimum flag those dependencies. For example if a new datatype depended on Perl6, it must check that Perl6 is installed before actually installing itself. We have a lot of little solutions and none of them are that far away from each other. I believe the trend is already to use "what worked for that other project". The issue then is to encourage projects on pgfoundry to discover the exact installation standard and promote it. The individual project owners will be required to implement them. Another aspect is that little code clips, from my site and from previous published papers and/or presentations should probably be collected somehow. I think this may be a different class of object, though. I already have a web page of these and it surely can be added to (feel free to recommend some!). But the installation of these fragments is usually cut and paste. --elein elein@xxxxxxxxxxx On Mon, May 22, 2006 at 05:38:35PM +0200, Florian G. Pflug wrote: > Agent M wrote: > >I think the implementation of postgresql installable packages (and > >package-space) should precede this idea. Then, any package management > >system can install the packages. > > Having a standardizes package management for postgresql would be great. > I believe one could use schemas to encapsulate installed packages, but > maybe some backend support would be necessary for dependency tracking. > > Oracle seems to support some kind of "package" concept - does anyone know > any details? > > greetings, Florian Pflug > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings >
