Skip site navigation (1) Skip section navigation (2)

Re: Inline Extension

From: Peter van Hardenberg <pvh(at)pvh(dot)ca>
To: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, Daniel Farina <daniel(at)heroku(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Inline Extension
Date: 2012-01-27 09:46:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Jan 26, 2012 at 3:48 PM, David E. Wheeler <david(at)justatheory(dot)com> wrote:
> On Jan 26, 2012, at 9:40 AM, Dimitri Fontaine wrote:
>> Not for 9.2, but I can't help thinking that if we could manage to host
>> the .so module itself in the catalogs, we could solve updating it in a
>> transactional way and more importantly host it per-database, rather than
>> having the modules work per major version (not even per cluster) and the
>> extension mechanism work per-database inside each cluster. But that's
>> work for another release.
> +1 Cloud vendors will *love* this.


Let me share my perspective. I'll begin by describing the current
state of runtime code dependency management for comparison.

In Ruby, any user can push an application to our platform which relies
on any/every ruby "gem" ever released (give or take). These gems may
require exact releases of other gems, have elaborate system
dependencies, and/or natively compiled code components. This is thanks
to the repository, the "gem" system, and recently but
crucially, the "bundler" system for resolving and isolating
dependencies. Releasing a new gem takes moments and I have personally
released a half dozen of no real consequence to the world which I use
from time to time.

In contrast, the idea that any person or team of people could possibly
review the literally hundreds of gems released each day is no longer
plausible. The only feasible solution for providing a robust service
is to engineer a solution which can be operated from inside the
cluster to install any library whatsoever.

Our aim is, put simply, to be able to support every extension in the
world, at once, under cascading replication, across major catalogue
upgrades. We hope this ideal is shared by the community at large,
since our problems are generally the same as other users, just writ


PS: As an aside, because of the many problems with in-cluster
multi-tenancy (to pick just one example, resource isolation between
users) I have no security concerns with giving users every ability to
execute code as the cluster owner's UNIX user. On our service we do
not restrict our users access to superuser out of spite, but to reduce
the available surface area for self-destruction.

Peter van Hardenberg
San Francisco, California
"Everything was beautiful, and nothing hurt." -- Kurt Vonnegut

In response to

pgsql-hackers by date

Next:From: Dean RasheedDate: 2012-01-27 09:57:17
Subject: Re: patch: ALTER TABLE IF EXISTS
Previous:From: Kyotaro HORIGUCHIDate: 2012-01-27 08:57:01
Subject: Re: Speed dblink using alternate libpq tuple storage

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group