Search Postgresql Archives

Re: Let's make CPgAN!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux