> Если мелкий, то проще за кидать все в цте

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

> теша себя надеждой что оно не заинлайнится во что-то что с большими ошибками в вычисления кардинальности на исполнение пойдёт.)

Смысл inlining — ровно в обратном, в норме. ;) Конечно, бывает и наоборот. И "большие ошибки вычисления кардинальности"  не обязательно приводят к "плохим" планам; и, даже если приводят — их время исполнения может быть вполне приемлемым на практике.

> Среди бдшников ещё может быть что кто-то что-то вразумиьельное напишет,

Нормально писать запросы, в большинстве случаев, несложно.

> но вот бэкэндщики - сильно вряд ли.

Тогда с временными таблицами им всё удастся ещё хуже, нет?

> Про ситуацию. Она, точнее итоговый план на исполнение, чаще зависит от объема данных предполагаемых оптимизатором.

Да, конечно. Но вопрос в том, приводит ли это к проблемам на практике.

> Я видетел достаточно много $5к+ синьеров бэкэнд кто с эксплейном знаком на уровне "знаю что есть какая-то такая команда".

А оно им надо? Вряд ли кто-то сидит и "вытачивает" каждый используемый запрос.
Более того, то, что этой дурью маяться [почти всегда] не нужно, является существенным преимуществом SQL (по сравнению с получением того же результата "вручную", как это делали в не-SQL СУБД, если что). ;)

если поле находится на "верхнем уровне", то все просто data||'{"key":"new_value"}'::jsonb

это да, но там могут быть вложенности

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

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

тогда я вам выше все написал, jsonb_set ваше решение.

да. уже разобрался. просто думал какой то еще хакнутый метод подскажут

спасибо

Ок. Вы не видели как люди в стейтмент суют по 70 джойнов с подзапросами и тд. Поэтому вы глубоко уверены что всё всегда можно сделать одним стейтмент ом. Наш опыт в этом плане видимо сильно различается. Предлагаю эту часть вопроса закрыть. :)
Спорить по существу инлайна тоже смысла мало без конкретно поставленной задачи. Тоже предлагаю не придираться. В лбоом случае мы оба останемся при своём мнении. :)

Возможно вам попадались лишь хороши ребята. Но мне попадались например уверенные что мердж структура - это верх божественного просветления, и надо все писать на них. В том числе, например, делит и инсерт последовательно  из табы надо делать именно мердж запросом. И из двух строк кода получалось 25-30.
Бэ не знают скуль настолько глубоко чтобы намутить дичь. В основном. Но конечно есть и исключения, наверно. Не встречал.
Про оно им надо. Да, конечно, нафик им. Не их работа же. Но вот с утверждением что декларативность скуля решает полностью проблему оптимального исполнения кода я готов спорить очень сильно и очень очень долго. И я не про селектики с одним джойном. Пример кинуть навскидку конечно же не могу, но то, что порядок действий в стейтменте и игра с конструкциями, тем же цте, может кардинально изменить конечный план исполнения, как следствие и скорость - меня никто никогда не переубедит. :)

> Вы не видели как люди в стейтмент суют по 70 джойнов с подзапросами и тд.

Да, именно семьдесят — пожалуй, не видел (или, к счастью, забыл). ;)
Но это уже из области "нагородить ерунды в запросе", почти наверняка... нет?

> Поэтому вы глубоко уверены что всё всегда можно сделать одним стейтментом.

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

> Спорить по существу инлайна тоже смысла мало без конкретно поставленной задачи. Тоже предлагаю не придираться.

Вы предлагаете "не придираться" человеку, который чуть-чуть поучаствовал в разработке CTE inlining в PostgreSQL, если что. ;)
И делал я это не просто так, а потому, что вполне убеждён, что это поведение по умолчанию правильное и очень полезное (т.е. то, что этого не было / это было не так в PostgreSQL — это существенный недостаток).

> Возможно вам попадались лишь хороши ребята.

"Плохие" накосячат где и с чем угодно. ;) Т.е. ориентироваться на идиотов не стоит, в принципе.

> Да, конечно, нафик им. Не их работа же.

Нет, посыл не в этом, а в том, что всё приемлемо работает и так. И это так для подавляющего большинства запросов / в большинстве случаев.

> Но вот с утверждением что декларативность скуля решает полностью проблему оптимального исполнения кода

Никто этого и не утверждал. Более того, это не является задачей планировщика!
Его задача, грубо говоря — построение достаточно хороших планов для идиоматических запросов за приемлемое время.
Кстати, нередко как раз из-за неправильного понимания вышеописанного авторы различных идей и patches по "улучшению" планировщика удивляются (а то и обижаются), когда их "ценный" вклад отвергается сообществом проекта PostgreSQL.

> может кардинально изменить конечный план исполнения, как следствие и скорость

Какая-то — может, какая-то — нет. ;) Суть-то не в "скорости", опять-таки.

Всем привет. Вопрос от новичка.
Реализация many to many field всегда происходит с промежуточной таблицей или есть другие варианты реализации?

Если коротко - всегда.

Привет. Я только начинаю пользоваться постгресом. Создала нового пользователя(root) и новую базу для него(base). Как зайти в psql из-под нового пользователя? если делаю psql -U postgres то я же захожу под юзером постгрес?   Если делаю psql -U root , то возвращается, что бд root не существует. Если делаю psql -U base, то возвращается, что роль base не существует. Как работает эта команда, ткните на ресурс, где это можно почитать.

Надо параметр базы указывать и параметр пользователя

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

есть, массивы, jsonb-но только когда понимаете зачем и чем это грозит.

Не помню. Я в таких случаях захожу как postgres

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

вообще то postgres пользователь DBA его никому не отдают