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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to