Dawid Kuroczko wrote:
On 5/22/06, Florian G. Pflug <fgp@xxxxxxxx> 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 didn't suggest using apt-get/rpm/whatever, I was just trying to say
that while now 100% perfect solution for package management exists (be
it for databases or for operating systems), there are still quite good
solutions, which work "in the real world".
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. :)
full ack.
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.
If the package contains only non-user-modifyable objects, then one
could "cheat" by dropping the whole schema the package lives in, and
recreating it from scratch.
But of course this has quite a few downsides - it would make it impossible
for user of packages to use types or views the package provides.
greetings, Florian Pflug
