In late 1996, we changed our name from POSTGRES95 to POSTGRESQL. It is a mouthful, but honors our Berkeley name and touts our SQL capabilities. We started distributing our 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 were every 3-5 months. This consisted of 2-3 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 do a more aggressive schedule with more releases. A database server is not like a word processor or a game, where you can easily restart it if there is a problem. Databases are multi-user, and lock user data inside our servers, so we have to be very careful that released software is as reliable as possible.
Development of source code of this scale and complexity is not for the novice. We had trouble getting developers interested in a project with such a steep learning curve. However, our civilized atmosphere, and our improved reliability and performance, finally 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 TODO 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 back-end modules.3.5 We wrote a developers FAQ3.6, to describe some of the common questions of POSTGRESQL developers. With this, developers became more productive at fixing bugs and adding features.
The source code we inherited from Berkeley was very modular. However, most Berkeley coders used POSTGRESQL as a test bed for research projects. Improving existing code was not a priority. Their coding styles were also quite varied.
We wrote a tool to format/indent the entire source tree in a consistent manner. We wrote a script to find functions that could be marked as static3.7, or never-called functions that could be removed completely. These are run just before each release. A release checklist reminded us of the things that have to be changed for each release.
As we gained knowledge of the code, we became able to perform more complicated fixes and feature additions. We started to redesign poorly structured code. We moved into a mode where each release had major features, instead of just bug fixes. We improved SQL conformance, added sub-selects, improved locking, and added missing SQL functionality. We added commercial-style telephone support.
The Usenet discussion group archives started touting us. In the previous year, 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. This more clearly portrayed our strengths. Other databases were recommended when speed was the overriding concern. REDHAT'S shipment of POSTGRESQL as part of their LINUX3.8 distribution quickly multiplied our user base.
Every release is now a major improvement over the last. Our global development team now has mastery of the source code we inherited from Berkeley. Finally, every code 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 world-wide development team.