Re: Let's make CPgAN!

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