я свое решение выше написал, сделал бы кучу my_super_startup.env_777 в таком духе, а потом через current_setting забирал

Здравствуйте. Возникла проблема при upgrade с 11 на 12 версию PostgreSQL.
В файле лога pg_upgrade_dump_16388.log получаю ошибку:

pg_restore: creating VIEW "public.geography_columns"
pg_restore: creating VIEW "public.geometry_columns"
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 232; 1259 17268 VIEW geometry_columns demon
pg_restore: error: could not execute query: ERROR:  column s.consrc does not exist
LINE 28:             "replace"("split_part"("s"."consrc", ''''::"text...
                                            ^
HINT:  Perhaps you meant to reference the column "s.conkey" or the column "s.conbin".
Command was:
-- For binary upgrade, must preserve pg_type oid
SELECT pg_catalog.binary_upgrade_set_next_pg_type_oid('17270'::pg_catalog.oid);

-- For binary upgrade, must preserve pg_type array oid
SELECT pg_catalog.binary_upgrade_set_next_array_pg_type_oid('17269'::pg_catalog.oid);

-- For binary upgrade, must preserve pg_class oids
SELECT pg_catalog.binary_upgrade_set_next_heap_pg_class_oid('17268'::pg_catalog.oid);

все расширения установил в точности такие же что и на старой версии

вот этим как раз студенты и отличаются от разработчиков с опытом :)
опытные уже знают, в каких случаях удобнее забить на все курсы проектирования

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

Вот конкретный пример: хранение настроек виджетов. Текущая классическая реализация соответствует канонам проектирования реляционныхз БД. И это решение, помимо всего прочего расширяемое и масштабируемое. А вот попытка переделать на какой-нибудь джсон(б) гарантированно приведёт к проблемам с производительностью, расширяемостью и масштабированием.

И что же говорит о мыскле?

комменты)

вот ничего не могу сказать по поводу текущей реализации и ее соответствия чему-либо, так здесь ничего не сказано про условия задачи.

но вполне могу себе представить ситуацию, когда в процессе разработки могла получиться таблица с одной строкой и десятками колонок.
Эта ситуация не то чтобы очень правильная, но в ней самой по себе нет ничего такого страшного, просто надо понимать границы применимости.

А что насчёт реляционности?
ЗЫ. БД на мыскле, в силу неразвитости богомерзкой носкульщины, ака джсон(би) вообще должен соответствовать реляционной модели. Хых.

реляционность сама но себе как таковая нахнен никому не сдалась :))

Самое главное: отступление от канонов и курсов проектирования приводит к узкому решению текущей конкретной задачи. Как показывает опыт, впоследствие требуется и расширение, и масштабирование. Плюс увеличивается объём данных. Результат: начинается переделка и приведение решения к каноническому виду. Вот такие вот пироги. И даже по обсуждению именно в этом чате таких задача (приведение к каноническому реляционному виду) - по несколько раз за день.

как показывает опыт, если он есть, то отктупдление от канонов может быть оправдано в любом месте.

Я надеюсь, это шутка такая. А то меня подобные заявления весьма серьёзно достают, ибо см. про масштабируемость, расширяемость и производительность. Я подобных вещей помимо чатика нахапался.

Ну-ну. Удачи.

нет, это заявление человека с некоторыи опытом разработки и эксплуатации :))

а неудобство этого метода хранения выползет сразу же, как только понадобится изменить конструкцию какого-то отдельно взятого виджета. Например, пусть виджет имеет 3 настраиваемых параметра (текст заголовка, контент и свич вкл\выкл). В текущем виде это означает, что на 3 этих параметра нужно в БД иметь 3 отдельных поля. И необходимость добавить новый изменяемый параметр или удалить один из старых прямо приводит к необходимости правки структуры таблицы. Тогда как имея структуру типа (id, name, value) достаточно было бы переписать поле value (JSON или просто сериализованный массив в текстовом поле) в строке с соответствующим id или name 🤷🏻‍♂️ Ну еще on/off можно оставить в виде числового или булевого поля)

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

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

Ну насчёт расширяемости и джсон вы погорячились, а если там всего одна запись, то и с производительностью.

В монге атомарная работа в пределах документа , а в постгресе ты можешь все в транзакцию завернуть, вплодь до изменения схемы.

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

А еще это значит что разработчики могут спокойно глобальный стэйт запихнуть без какой-либо изоляции в одно хранилище
потому что хранилище защитит от дурачков

Скажем с тем же jsonb это удобно но это абсолютно не значит что у jsonа этог оне будет никакой схемы. И ты можешь даже констрейны прописать:
ALTER TABLE jsontable ADD CONSTRAINT uuid_must_exist CHECK (j ? 'uuid');

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

Сегодня твой маленький сервис маленький а завтра тебе руководство говорит "надо срочно мультирегиональный деплоймент что бы данные волшебным образом реплицировались по всему миру с целью уменьшения лэтенси" и ты такой "о, збс, у меня стэйт разделен на агрегаты и я могу запихать все в dynamodb global table и пить смузи.

Ну и как не странно монга хороша там, где с данными нужно работать как с документами, какой-нибудь ЭДО, опросили аля Гугл формы