galaxy

Ну соберите обратно в массив

select array_agg(v)
  from (select jsonb_array_elements(col)->'a' v
	  from (values ('[{"a": 1, "b": 2}, {"a": 10, "b": 20}]'::jsonb)) as t(col)
	) t1

SELECT SUM (CASE WHEN status = 1 THEN amount END) as sum1, ... FROM ... GROUP BY ..

Смотря какая именно задача.

Для совсем произвольных объектов - jsonb (ну или jsonb[], чтобы был массив).

Если объекты одной структуры, можно создать свой композитный тип и колонку typename[].

Да ерунду вы затеяли с этой схемой.
Попробуйте
SET search_path TO test, public;

Ну что-то типа:

select distinct pbx_call_id,
       first_value(clid) over (partition by pbx_call_id order by callstart) clid,
       ... -- остальные поля
  from calls;

По второму вопросу, так можно собрать то, что нужно в колонку

select pbx_call_id,
       jsonb_agg(json_build_object('disposition', disposition, 'sip', sip)) as sips
  from calls
 group by pbx_call_id

ALTER TABLE posts
DROP CONSTRAINT authorID;

С чего вы решили, что констрейнты называются именем колонок?
Я думаю, у вас этот запрос выдал ошибку, и ваш первоначальный констрейнт не удалился.
Смотрите, какие внешние ключи есть на таблице, в psql командой \d+ posts.

Ну так английским же языком пишет - нет unique constraint на группу полей, на которую ссылаетесь (uuid_vm, name_vm, bg_date, end_date).

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

pgAdmin3 - отдельный софт
Большинство других gui клиентов - платные. Хотя если вас устроят ограничения, есть бесплатная версия у EMS SQL Manager (я когда-то пользовался, в принципе норм).

И вообще, выбирайте

Нетипичная задача, обычно данные не таскают из партиции в партицию.
Тем не менее, ничего сложного нет. Делаете BEFORE UPDATE FOR EACH ROW триггер на дочерние таблицы. При апдейте на родительской таблице автоматически будет сделана попытка проапдейтить соответствующую строку дочерней и вызовется триггер. Триггерная функция должна проверить, должны ли данные остаться в текущей партиции (и в этом случае ничего не трогать) или, соответственно, удалить их из текущей и перенести в нужную. Короткий пример:

-- ключ нужен, чтобы точно идентифицировать строку таблицы
create table t(id int primary key);

-- партиции, без триггеров на INSERT
create table t1(primary key (id), check(id > 0 and id <= 10)) inherits(t);
create table t2(primary key (id), check(id > 10 and id <= 20)) inherits(t);

insert into t1 values (1), (4);
insert into t2 values (15);

test=# select * from t;
 id
----
  1
  4
 15

test=# select * from t1;
 id
----
  1
  4
 
test=# select * from t2;
 id
----
 15


create or replace function t_tg_proc() returns trigger as $$
begin
	raise notice 't_tg_proc called';
	if TG_TABLE_NAME = 't1' and NEW.id > 10 then
		delete from t1 where id = OLD.id; -- без primary key можно удалить лишнего
		insert into t2 values (NEW.*);
		return null; -- проигнорировать UPDATE
	end if;
	
	if TG_TABLE_NAME = 't2' and NEW.id <= 10 then
		delete from t2 where id = OLD.id;
		insert into t1 values (NEW.*);
		return null; -- проигнорировать UPDATE
	end if;
	
	return new; -- нормальный UPDATE
end $$ language plpgsql;

create trigger t1_tg before update on t1 for each row execute procedure t_tg_proc();
create trigger t2_tg before update on t2 for each row execute procedure t_tg_proc();

-- обычный UPDATE
update t set id = 5 where id = 4;
ЗАМЕЧАНИЕ:  t_tg_proc called
UPDATE 1

select * from t;
 id
----
  1
  5
 15
 
-- необычный UPDATE
update t set id = 11 where id = 1;
ЗАМЕЧАНИЕ:  t_tg_proc called
UPDATE 0

select * from t;
 id
----
  5
 15
 11
 
test=# select * from t1;
 id
----
  5
 
test=# select * from t2;
 id
----
 15
 11

Хмм… а исключающие чеки у вас есть на дочерних таблицах (т.е. alter table cdr_data_90mln add constraint cc_cdr_data_90mln check (id >= 90000000 and id < 95000000) )?