> Не надо стремиться сделать все в один стейтмент.

Эээ... почему? Если нужен какой-то результат, который можно получить запросом — почему бы его не написать?

> Вы и себе проблему создаёте на ровном месте

Какую?

> и коллегам вне контекста вашей задачи жизнь усложняете в понимании в дальнейшем вашего кода. :)

Аккуратно написанный код с использованием последовательности CTE обычно не менее (а то и более) понятен, чем то же самое с временными таблицами, IMHO.

> Не стройте 100500 этажей.

Последовательность CTE не выглядит, как "100500 этажей".

> Не надейтесь что функция развернется|не развернётся на этапе оптимизации.

Хмм... а кто-то что-то говорил про оптимизацию? ;)

Народ, как можно ипортировать csv файл в таблицу, когда у csv поля перемешаны?
Я думал что если в COPY добавить CSV HEADERS - он прочитает заголовки полей и сопоставит их с полями таблицы, но чето так не работает

Можно авком например восстановить их порядок

Или катом даже

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

Не могу с телефона так же нацитировать, так что постараюсь понятнее написать. :)
Проблема - это когда можно сделать просто, но вместо этого делается сложнее. Мы же это видели не так давно с тру сишниками олдскульными. :)
Цте или таблички - дело обычно конкретной ситуации. Зависит ещё от кол-ва джойнов. Это основная мысль на которую опирался.
Вы просто не видели как люди неконтролируемо этадирубт цте наверно. :)

Оптимизация которую я имел в виду не та, что мы проводим ручками применяя моцк, а та, что делает движок. Конкретно я имел в виду что функция может либо заинлайниться, либо тупо вызывать ся в лупе. Это надо понимать и учитывать тк это может быть в одном случае хорошо, а в другом плохо. :)

Вручную можно сопоставить (header просто пропускает строку-заголовок), как-то так:

COPY some_table(first_column_in_the_file, second_column_in_the_file, ...) FROM 'a_file.csv'
WITH (FORMAT CSV, HEADER true);

Я так и понял, щас в bash вырезаю первую строку и использую ее для определения последовательности колонок

А как можно заменить пустые строки на '' а не null ?

> Проблема - это когда можно сделать просто, но вместо этого делается сложнее.

И "сложнее" — как раз использование temporary tables вместо CTE, нет?

> Зависит ещё от кол-ва джойнов. Это основная мысль на которую опирался.

Разве что производительность может быть разной (и, в обычных случаях — у одного statement с CTE и JOINs она лучше, чем у многих с temporary tables).

> Вы просто не видели как люди неконтролируемо этадирубт цте наверно. :)

Что Вы имеете в виду? Обычно их, наоборот, используют недостаточно, IMHO. ;)

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

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

Попробуйте FORCE_NOT_NULL (если я правильно понял, что нужно).

да, оно, только ему все равно надо явно задавать поля, ну то я сделаю

спасибо большое

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

грубо говоря у меня сейчас вот так

user_id | customer_id
 10           5
 11           6
 12           7

и на других таблицах завязки FK по customer_id

+ я пользовался ОРМкой (ef core) и она не делала fk cascade update
в SQL я только могу какие то запросы небольшие пилить, а эту беду пофиксить не могу, может кто помочь выровнять айдишники кастомеров по user_id и как это сделать на зависимых табличках?

Вы попали:(

Fk переделайте руками на update cascade везде и поменяйте, проблем то?

Да не думаю

Зависит от величины запроса вообще. Если мелкий, то проще за кидать все в цте, теша себя надеждой что оно не заинлайнится во что-то что с большими ошибками в вычисления кардинальности на исполнение пойдёт.)
Про то как кто что использует. Есть БД разработчики и есть бэкэндщики, которые думают что они убер БД шарильщики. Среди бдшников ещё может быть что кто-то что-то вразумиьельное напишет, но вот бэкэндщики - сильно вряд ли. Темболее среди них полно адептов орм. И неизвестно кто более дикий запрос составит, они или орм.
Про ситуацию. Она, точнее итоговый план на исполнение, чаще зависит от объема данных предполагаемых оптимизатором. Опять же про разных людей. Я видетел достаточно много $5к+ синьеров бэкэнд кто с эксплейном знаком на уровне "знаю что есть какая-то такая команда". :)

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

Всем привет! есть поле JSONB и там нужно обновить KEY. такие обновления будут очень редко. есть вариант с REPLACE data::text но что-то не нравится. Подскажите пжл, какие еще есть менее затратные варианты ?