Re: Core Extensions relocation - Mailing list pgsql-hackers

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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us