Dawid Kuroczko wrote:
> 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 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