izMBG, вы все понятно разъясняете, во многом я с вами согласен. Но вы все же представляете очень редкое меньшинство. Не каждый возьмется писать полнотекстовый поиск в SQLite самостоятельно.

Разработчик модуля известен и доступен в рассылке и по почте; над чем сейчас идет работа, известно; как подключить свое расширение для поиска, разработчик подробно объяснил в рассылке, когда был задан соответствующий вопрос. Также известно, что есть несколько человек, кто готов помочь с тестированием (не русского языка, разумеется, но это не важно). Плюс код компилируется как загружаемая библиотека (или вместе с движком, при желании).

Вот хотелось бы и для постгреса чтоб была подобная инфраструктура для разработки. И перевод документации тут явно не поможет, поскольку язык общения в рассылках и по почте - английский. Чтобы этого добиться, нужно четко определить цели и задачи проекта. Если пять лет назад я знал, как позиционировать постгрес, то теперь уже затрудняюсь - открытых проектов стало очень много, да и требования с каждым годом растут. Слоган "самая продвинутая из открытых СУБД" уже ни о чем не говорит, ведь есть и более быстрые, и меньшие по размеру, и имеющие больше модулей, и умеющие распараллеливаться, и работающие на кластере...

Что касается соответствия стандарту SQL, то тут, признаться, не могу сравнивать - в основном работа идет из приложений через биндинги к тому или иному языку, через psql запускаю только скрипты, а там стараюсь не мудрить, иначе себе дороже - через год-другой разбираться в запутанном sql. Да еще и постгрес (как и эскулайт) давно обвешал наборами своих функций, сразу и не вспомнишь, что из стандартного комплекта. Года четыре назад постгрес действительно прекрасно соответствовал стандарту, так что будем считать, что и сейчас так оно и есть. Но вот биндинги к постгресу весьма посредственные, приходится свои обертки писать. А ведь, как говорится, "театр начинается с вешалки".

Прошу прощения, что вытаскиваю эту тему снова, но появилась новая информация к размышлению. См.
http://www.opennet.ru/opennews/art.shtml?num=17234

Лучшие СУБД по оценке SD Times:


Кажется, комментарии излишни.

Author the new one
Конечно. Вот SQL Anywhere новый вышел. Он позиционируется как мелкий сервер на побегушках, между прочим. Просто сравните:

http://www.sybase.com/files/White_Papers/Sybase_SQLAnywhere_Top10newFeatures_wp.pdf

Ух ты, Unload to variable и Openstring я тоже хочу. Буду думать, как это в эскулайте сделать.

Author the new one MBGУх ты, Unload to variable и Openstring я тоже хочу. Буду думать, как это в эскулайте сделать.

А Immediate Materialized Views - не? Мегавещь же. А MERGE?

Openstring на тикле сделал, ничего хорошего - для больших таблиц выделяется большой блок памяти под строку, неэффективно. Выгоднее действовать стандартно - реплицировать таблицу в новую базу и ее пересылать как файл, с диска читается кусками, много памяти не требует. А делать Openstring в файл смысла вообще нет, лучше сразу реплику в файл делать. Это если для пересылки данных - а для работы в пределах одной базы так и вовсе временная таблица лучшее решение.

Materialized Views всех видов реализуются виртуальными таблицами или триггерами, если не находится готовой реализации, делается своя. Ага, на С надо писать, но в этом есть свои прелести.

MERGE вообще не понял зачем, это и так реализуется стандартными запросами.

Последнее время думаю о том, что одной полезной штуки я не видел ни в какой СУБД - фоновой нормализации таблицы, чтобы запись в широкую таблицу на лету превращалась в запись в множество связанных таблиц, это позволит оптимизировать и объем хранимых данных и скорость многих выборок.