Re: Let's make CPgAN!
От | Florian G. Pflug |
---|---|
Тема | Re: Let's make CPgAN! |
Дата | |
Msg-id | 4471FE83.4010206@phlo.org обсуждение исходный текст |
Ответ на | Re: Let's make CPgAN! (elein <elein@varlena.com>) |
Ответы |
Re: Let's make CPgAN!
Re: Let's make CPgAN! |
Список | pgsql-general |
elein wrote: > This issue is a very old issue and people have not come up with > the definitive solution to distributing "datablades" as Stonebraker > called them. True, but OTOH there is no "definitive solution" for OS-level package management too, but still "apt-get" or "rpm" do a pretty decent job. So, 99% solutions are possible ;-) > 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. The problem is not such much the initial installation, but rather upgrade to new versions of either the "package", or postgresql. > 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. I'd really like to see a solution that enables me to install a package using something like "pgpkg install <dbname> <package>". I'd ask me to install prerequisites (like procedural languages for example). pg_dump should have an option to exclude any installed packages from the dump. As long as "packages" only contain functions, views and types, things are quite straight forward, I believe. The hard part would be to support packages including table-definitions. What do you do when an upgrade wants to modify a table, but it already contains user data? greetings, Florian Pflug
В списке pgsql-general по дате отправления: