next up previous contents index
Next: Open Source Software Up: History of POSTGRESQL Previous: Development Leaves Berkeley

  
POSTGRESQL Global Development Team

In late 1996, we changed the name of the database server from Postgres95  to POSTGRESQL. It is a mouthful, but honors both the Berkeley name and its SQL capabilities. We started distributing the source code using remote cvs, which allowed people to keep up-to-date copies of the development tree without downloading an entire set of files every day.

Releases occurred every three to five months. Each period consisted of two to three months of development, one month of beta testing, a major release, and a few weeks to issue sub-releases to correct serious bugs. We were never tempted to follow a more aggressive schedule with more releases. A database server is not like a word processor or game, where you can easily restart it if a problem arises. Instead databases are multiuser, and lock user data inside the database, so they must be as reliable as possible.

Development of source code of this scale and complexity is not for the novice. We initially had trouble interesting developers in a project with such a steep learning curve. However, over time, our civilized atmosphere and improved reliability and performance helped attract the experienced talent we needed.

Getting our developers the knowledge they needed to assist with POSTGRESQL was clearly a priority. We had a TODO list that outlined what needed to be done, but with 250,000 lines of code, taking on any item was a major project. We realized developer education would pay major benefits in helping people get started. We wrote a detailed flowchart of the database modules.6.5 We also wrote a developers' FAQ,6.6 answering the most common questions of POSTGRESQL developers. With this information, developers became more productive at fixing bugs and adding features.

Although the source code we inherited from Berkeley  was very modular, most Berkeley coders used POSTGRESQL as a test bed for research projects. As a result, improving existing code was not a priority. Their coding styles were also quite varied.

We wrote a tool to reformat the entire source tree in a consistent manner. We wrote a script to find functions that could be marked as static6.7 or unused functions that could be removed completely. These scripts are run just before each release. A release checklist reminds us of the items to be changed for each release.

As we gained knowledge of the code, we were able to perform more complicated fixes and feature additions. We redesigned poorly structured code. We moved into a mode where each release had major new features, instead of just bug fixes. We improved SQL conformance, added sub-selects, improved locking, and added missing SQL functionality. A company was formed to offer telephone support.

The Usenet discussion group archives started touting us. At one time, we had searched for POSTGRESQL and found that many people were recommending other databases, even though we were addressing user concerns as rapidly as possible. One year later, many people were recommending us to users who needed transaction support, complex queries, commercial-grade SQL support, complex data types, and reliability--clearly our strengths. Other databases were recommended when speed was the overriding concern. Red Hat's shipment of POSTGRESQL as part of its Linux 6.8 distribution quickly expanded our user base.

Today, every release of POSTGRESQL is a major improvement over the last. Our global development team has mastery of the source code we inherited from Berkeley . In addition, every module is understood by at least one development team member. We are now easily adding major features, thanks to the increasing size and experience of our worldwide development team. 


next up previous contents index
Next: Open Source Software Up: History of POSTGRESQL Previous: Development Leaves Berkeley
Bruce Momjian
2001-05-09