Когда я примерно шесть лет назад пытался понять, какую СУБД следует использовать для обеспечения эксперимента, в котором я участвую до сих пор, то выбора просто не существовало. Из свободных СУБД только PostgreSQL на тот момент обладал необходимой функциональностью. На сегодня вопрос выбора немного усложнился: подрос в хорошем смысле этого слова MySQL (в последней, 5-ой версии, говорят, наконец-то даже триггеры появились), были открыты исходные тексты проекта Firebird, в девичестве Interbase от фирмы Borland, да и «игрушечные» проекты типа SQLite тоже не лишены определенных преимуществ. Ну и, естественно, свет клином на открытых проектах не сошелся – тот же Oracle [бесплатно] предлагает свои СУБД для изучения. И все-таки я выбираю PostgreSQL – решение шестилетней давности меня не разочаровало. На редкость устойчивая к внешним воздействиям программа с абсолютно предсказуемым поведением. Даже те случаи, которые мне по неопытности показались «граблями», оказались «фичами».

Одной из основных целей, которая была поставлена при разработке PostgreSQL, является строгое соответствие стандартам. PostgreSQL поддерживает ANSI SQL–92, SQL–99 (SQL–2 и SQL–3, соответственно), а также многие из возможностей ANSI SQL:2003. Мало кому^[10] удается похвастаться подобным соответствием стандартам.

В дополнение к стандартам, PostgreSQL поддерживает множество полезных расширений. Примером мелкого, но полезного расширения, не входящего в стандарт SQL, являются дополнения к условию для SELECT вида LIMIT/OFFSET^[11], которые позволяют получить только указанные строки из результата запроса. PostgreSQL полностью поддерживает механизм транзакций (transactions), вложенные запросы (subselects), триггеры (triggers), представления (views), функциональные индексы, ссылочную целостность по внешнему ключу (foreign key referential integrity), изощренные типы блокировок (sophisticated locking) и многое другое.

К названию PostgreSQL обычно прибавляется слово «объектная», то есть полное наименование звучит как «объектно-реляционная база данных PostgreSQL». Пользователю предоставляются необходимые инструменты для создания новых типов данных, функций, операторов и своих методов индексирования. Подобные возможности позволяют работать с довольно нестандартными данными, например, с картографическими объектами – PostGIS (http://postgis.refractions.net/).

Размер базы данных, управляемой PostgreSQL, не ограничен, также нет ограничения и на число строк в таблице. Да и вообще, есть ли ограничения у этого чуда? Да, есть: ваша таблица не может быть больше чем 32 Тбайта, а число столбцов в таблице не может быть больше 250–1600, в зависимости от типа данных. Много это или мало? Зависит от задачи: я, например, как-то уперся в ограничение по числу столбцов, но скорее по неопытности, нежели по необходимости. Описанное выше верно для версии PostgreSQL 8.1.4. Возможно, в будущем будут сняты и эти ограничения.

Существует родные интерфейсы для работы с PostgreSQL из языков Java (JDBC), Perl, Python, Ruby, C, C++, PHP, Lisp, Scheme и всего, что может связаться через ODBC. PostgreSQL поддерживает хранимые процедуры, которые можно написать на множестве языков программирования, включая Java, Perl, Python, Ruby, Tcl, C/C++ и родном для PostgreSQL PL/pgSQL.

По результатам автоматизированного тестирования, проведенном в 2005 году (http://www.postgresql.org/about/news.363), в коде PostgreSQL было обнаружено 20 дефектов, что соответствует 1 ошибке на 39 тысяч строк кода. Для сравнения, аналогичное тестирование примерно в то же время выявило по одному дефекту на 10 тысяч строк кода в ядре Linux, а в MySQL одно проблемное место приходится на 4 тысячи строк кода. Это ни о чем не говорит, так сказать, мелочь, зато разработчикам и пользователям PostgreSQL приятно.