On 5/22/06, Florian G. Pflug <fgp@phlo.org> wrote:
> 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 ;-)
Yet a RPM/DPKG/whatever will only make a collection-wide installation,
or rather preparation of package. Think: PLpgSQL. It is installed by
default. But to use it, you have to actually createlang it into your
specific database.
I think the "CPgAN" should aim at the latter (managament of "packages"
throughout whole PostgreSQL collection) and help with the former
(make it easy to rpmify/dbmify/whateverify the package; help with
raw source-installation/update) at the same time. It is what C*ANs
do to other projects. :)
> 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?
Tricky. Ideally it should either upgrade it, if possible, or fail
with some hints how to update the structure manually.
And it can happen to functions views (think views depending
on views) and types also.
Regards,
Dawid