From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Dawid Kuroczko <qnex42(at)gmail(dot)com> |
Cc: | Agent M <agentm(at)themactionfaction(dot)com>, Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Let's make CPgAN! |
Date: | 2006-05-22 22:13:21 |
Message-ID: | 44723781.9010607@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dawid Kuroczko wrote:
> On 5/22/06, Florian G. Pflug <fgp(at)phlo(dot)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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-05-22 22:14:55 | Re: Let's make CPgAN! |
Previous Message | Jim C. Nasby | 2006-05-22 22:12:40 | Re: ALTER SEQUENCE ... RESTART WITH [variable] problem |