Re: Core Extensions relocation

On 11/18/2011 03:36 PM, Josh Berkus wrote:
> Of course, packagers may then reasonably ask why that code is not just
> part of the core?
>

Let me step back from the implementation ideas for a minute and talk
about this, and how it ties into release philosophy. The extensions
infrastructure for PostgreSQL is one of its strongest features. We can
use it as a competitive advantage over other databases, one that can
make this database stable and continuously innovating at the same time.
But that's not happening enough yet; I feel this change is a major step
in that direction. There's no demonstration that extensions are edible
dog food like the core database visibly eating a can.

To see why this matters so much, let's compare two stereotypes of
PostgreSQL users at different extremes of upgrade tolerance. First we
have the classic enterprise DBA. Relative to this person's
expectations, PostgreSQL releases are way too fast. They can't upgrade
their database every year; that's madness. This is the person who we
yell at about how they should upgrade to the latest minor point release,
because once they have a working system they touch *nothing*. For this
user, the long beta period of new PostgreSQL releases, and its general
conservative development model, are key components to PostgreSQL being
suitable for them.

At the other extreme, we have the software developer with a frantic
development/release schedule, the one who's running the latest stable
version of every tool they use. This person expects some bugs in them,
and the first reaction to running into one is to ask "is this fixed in
the next version?" You'll find at least one component in their stack
that's labeled "compiled from the latest checkout" because that was the
only way to get a working version. And to them, the yearly release
cycle of PostgreSQL is glacial. When they run into a limitation that is
impacting a user base that's doubling every few months, they can't wait
a year for a fix; they could easily go out of business by then.

The key to satisfying both these extremes at once is a strong extensions
infrastructure, led by the example of serious tools that are provided
that way in the PostgreSQL core. For this to catch on, we need the
classic DBAs to trust core extensions enough to load them into
production. They don't do that now because the current contrib
description sounds too scary, and they may not even have loaded that
package onto the server. And we need people who want more frequent
database core changes to see that extensions are a viable way to build
some pretty extensive server hacks.

I've submitted two changes to this CommitFest that are enhancing
features in this "core extensions" set. Right now I have multiple
customers who are desperate for both of those features. With
extensions, I can give them changes that solve their immediate crisis
right now, almost a full year before they could possibly appear in a
proper release of PostgreSQL. And then I can push those back toward
community PostgreSQL, with any luck landing in the next major version.
Immediate gratification for the person funding development, and peer
reviewed code that goes through a long beta and release cycle. That's
the vision I have for a PostgreSQL that is simultaneously stable and
agile. The easiest way to get there it is to lead by example--by having
extensions that provide necessary, visible components to core, while
still being obviously separate components. That's the best approach for
proving this development model works and is suitable for everyone.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us