Чувствую, что к предыдущему посту требуется пояснительная бригада.

Я не призывал заменить все приложения на SQL. Я ж не из компании Oracle :)
И не из Lingualeo :)

Совершенно необязательно подобным образом генерировать весь код приложения. Можно генерировать код только для точек сопряжения приложения и базы.

Мне любезно подсказали инструмент, который решает ту же проблему:
https://github.com/adelsz/pgtyped

Задумано красиво - берем запросы, берем готовую запущенную(!) базу, делаем prepared statements, понимаем что будет на выходе.

Несомненный плюс - невозможно накосячить. Типы будут экспортированы точно так как нужно, а не так, как запрограммировал какой-то анон из интернета.

Но не обошлось без минусов:
- работает только с Postgresql
- экспортирует только в ts
- ничего не знает про nullability результатов
- ничего не знает про класс количества строк

Если про первые 2 пункта все понятно, то про важность последних поговорим отдельно.

Если вы пишете не на Java, где любая переменная может быть null, то довольно много логики может быть завязано на то, может ли переменная принимать значение null или нет.
Читаешь из ответа поле и используешь его в качестве индекса массива или имени свойства объекта? Молодец, лови undefined! Или сегфолт.
Или проверяй каждый раз - null или нет. И думай что делать, если null, которого быть не должно.

WTF класс количества строк?
Статическими методами, естественно, невозможно оценить сколько точно строк вернет запрос. Но можно попробовать рассчитать количество в следующих категориях - NONE, ONE, ONE OR NONE, MANY, MANY OR NONE. Если вы пишете на js и используете pg-promise, то в нем есть методы с соответствующими названиями, которые автоматически делают assert.

Зачем?
Обычно я привожу такой пример.
Пишите вы финансовую систему. Есть у вас запрос, который создает ордер на вывод денег. И запрос сложный. С кучей изменяющих данные CTE, джойны из вьюх и вот это все.
И вы знаете, что он вернет ровно одну строку, в которой будет id нового ордера.
На самом деле вы ДУМАЕТЕ, ЧТО ЗНАЕТЕ. В случае со сложными запросами это практически нереально оценить на глаз. Особенно человеку, который только онбордится в проект.
Но допустим, что это реально так.

Вы написали тесты на этот функционал все вроде бы ок.

Но вот нужно сделать новую фичу. Вы, или что хуже, новый сотрудник, рефакторит базу. В процессе удаляет какой-то существующий констрейнт. Например, NOT NULL становится NULL.
Внимание, вопрос: сломается ли что-то из 500/1000/2000 запросов в вашей базе?

А это мы сейчас проверим! У нас же есть тесты! (гыгыгы)
Давайте опустим тот момент, что тесты не покрывают все возможные комбинации данных в базе.

Запустили тесты и... Все ок :) Старое поведение не поменялось.
Все задеплоили, ушли домой.

Но, как обычно, в ночь с пятницу на субботу, начали массово поступать данные от новой фичи.

И внезапно оказывается, что теперь запрос, генерящий ордера на вывод денег стали генерировать не 1 ордер и возвращать 1 строку, а генерит несколько ордеров и возвращает несколько строк...
И хорошо, если у вас не крипто проект.
Иначе в понедельник можно будет на работу уже не выходить, т.к. за выходные все деньги компании будут выведены.

-----

Есть еще много полезных вещей, которые можно извлечь из запроса, если парсить его целиком, а не читить, как pgtyped.

Например, список всех релейшенов (таблицы, вьюхи) и типы воздействия на них (SELECT/INSERT/UPDATE/DELETE)
Или список всех связей, которые есть в join/where.