А зачем их так передавать?

Так не будет работать. NEW нужно использовать внутри функции

https://postgrespro.ru/docs/postgrespro/9.6/plpgsql-trigger#plpgsql-dml-trigger вот описание переменных триггерный функций

у меня две разные таблицы, при каждой новой строке в таблице А, от-туда берутся некоторые параметры и делают апдейты в другой таблице Б

А триггер на какой таблице висит?

на первой

Тогда в чём проблема? структуру этой таблицы знаете. Просто внутри функции напишите new.my_field и всё. Тип выводится автоматически

insert into b (my_column_b) values (new.my_column_from_a);

Как-то так.

Вам лучше обернуть её в другую функцию, которая будет соответствовать требованиям к триггерным функциям. Её уже и вешать как триггер

не апдейтит

Потому что у вас триггер уровня оператора.

В триггерах уровня оператора и для команды DELETE этой переменной значение не присваивается.

Вам нужен триггер уровня строк.

о, вы сделали английскую версию, супер!
Впечатления - по-моему лучший визуализатор планов для постгреса, спасибо и респект!

да, а еще быстрый шаринг ссылки на план

omg 😆😅, спасибо брат

Подскажите плиз бестпрактис.. )
Проектирую в первый раз таблицы с данными юзера...

Есть юзер у которого кроме простых полей имени, id и т.д. есть поля которые сами по себе объекты с массивами данных.

Правильно эти объекты расположить в отдельных таблицах или же все данные которые касаются юзера должны лежать в табличке юзер?


Мне кажется, что логично разделить. Положить эти данные в отдельные таблицы, а при запросе юзера собирать всё в один объект и отправлять...

table_user 1234 =
{name: kolya, id:1234, userLocations : (link-to-table_locations)}

table_locations 1234 = [
{loc_id: 01, strit:12, city:London, home:24},
{loc_id: 02, strit:9, city:Pekin, home:1},
{loc_id: 03, strit:2, city:Sidney, home:5},
{loc_id: 04, strit:11, city:Rovno, home:2}, ]

Как-то так...

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