EAV что ли? :-)

Зачем?!
Когда в PostgreSQL есть наследование таблиц.

Если сильно хочется, то для каждого типа делаете наследника и там храните данные в типоспецфичном виде.
Можно еще посмотреть в сторону создания собственных типов (вроде бы есть примеры создания типа комплексных чисел и операции над ними)

Можно вообще использовать что-то типа рефлексии, как Java, используя метинофрмацию из БД.

kealog,

Ну правильно. Родитель ничего не знает о полях потомка. :-)
Запрос к родителю вернет вам только список полейю
А вот значения нет. Т.к. они строго типизированные, то в одно поле курсора они не войдут.
Либо вам нужно все приводить к одному типу (например varchar), но тогда типизация вам нафиг не нужна.

Вообще-то в докладе на конференции PGConf разработчики из PostgresPro не рекомендуют использовать JSON, JSONB для хранения данных, по которым потом будут строиться запросы и пр. Т.к. есть вероятность стремящаяся к 1, что это будет узким местом в производительности БД.

А так не совсем понятно, что вы хотите.
Если нужна строгая типизация, то "универсализма" не будет.
Вам нужно будет либо читать метоинформацию о типах в БД, либо самому где-то ее хранить.

Если же нужен не типизированный key-value, то возьмите NoSQL, они хотя бы оптимизированы под такое применение (читай выкинуто все лишнее).

Не совсем. Они предлагают "инструмент", но честно предупреждают, что от него нельзя ожидать чуда.
Т.е. в "общем случае" не структурированные данные (в виде JSON) будут по скорости проигрывать данным разложенным в РМД.
Соответственно "инструмент" нужно применять очень осторожно и думая.
Но если не хотите думать, то лучше его не использовать.

Ну как обычно "серебряной пули" нет.
Поэтому надо исходить из конкретных условий задачи.
И соответственно задаче использовать техническое решение.

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

У меня лично был пример, когда на проекте решили хранить сущности в JSON-ах.
Я когда пришел, сказал, что не надо было так делать. Но там уже 2/3 проекта или больше было уже сделано и сроки поджимали.
Потом при опытной эксплуатации вляпались, во все возможные проблемы.
Начиная от проблем с производительностью, заканчивая большим геморроем с созданием отчетов.

Вся сущность хранилась единым JSON'ом.
Сущности были версионированные и хранились в том же JSON'е.
НСИ хранились в одном большом JSONе.
Соответственно поиск по всему этому делу был очень долгий.
Если нужно было вытащить другую сущность по связи, опять лезем в JSON, чтобы ее вытащить.

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


И да. В зависимости от версии поля в сущностях могли меняться.
Для этого в том же JSON'е была метаинформация по полям.

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

P.S. Вообще-то в начале предполагали, что система будет на MongoDB, но потом заказчик продавил БД.
Почему не изменили способ хранения данных ХЗ, я пришел на проект когда он уже "горел", и дедлайны были почти просраны.
И моя задача было интеграция со внешними системами.
Так что я особо боли не чувствовал.
Но на митапах постоянно стоял вопрос о скорости работы БД.