Померимся цифрами?
Померимся цифрами? Есть ли связь между количеством строк исходного кода и богатством функциональных и нефункциональных возможностей СУБД? Скорее да, чем нет. Хотя конечно речь не о жестком соотношении, а скорее о корреляции этих показателей. ✔ В PostgreSQL на сегодня — около 2,1 млн строк на языке C. Много ли это? Зависит от того, с чем сравнивать. ✔ Например, в MySQL на сегодня 2.4 миллиона строк кода (С/С++), в MongoDB - чуть больше 2 миллионов строк С++ кода, в российском ClickHouse - 1.5 миллиона строк кода на языке С++, а в вот в SQLite всего 145 тысяч строк кода (на чистом С). ✔ Особняком в этом ряду стоит СУБД Oracle. В 1992 году в 7-ой версии этой СУБД было 1.5 миллиона строк кода на языке С, к 12-й версии (2017) размер кодовой базы дорос аж до 25 млн, а сейчас, по разным оценкам, он насчитывает от 35 до 40 млн строк исходного кода. Для понимания: одна только подсистема RAC в Oracle "весит" 1,6 млн строк, а in-memory-подсистема - почти 2 млн. Это сопоставимо с размером последней версии "ванильного" PostgreSQL. ✔ В нашей СУБД Digital Q.DataBase по состоянию на сегодня 4.6 миллиона строк исходного кода, из них 2.7 миллиона строк это код на чистом С, еще 0.3 миллиона строк это код на разных диалектах SQL, а остальное - это код на С++. Да, это более чем двукратный рост по сравнению с размером кода оригинального PostgreSQL, но всё же нам есть еще куда расти. ✔ Правда, у роста кодовой базы есть и обратная сторона. Говорят, что программный код Oracle 12 был настолько запутанным, что любое его изменение с высокой вероятностью ломало регрессионные тесты. Разработчикам приходилось действовать крайне осторожно внося изменения — своего рода плата за десятилетия эволюции. ✔ Так что пожелаем российским форкам PostgreSQL прирастать функциональностью и связанным с ней кодом (до 10–20 млн строк, почему бы и нет!), но при этом сохранять архитектурную внятность кода и надёжность тестов. Чтобы становиться сильнее, радовать новыми возможностями пользователей, но при этом не повторять чужих ошибок.