crause,

Нет. Любая функция исполняется в рамках транзакции вызывающего запроса.

crause
хранимка 1.
begin
хранимка2(параметры) -- успешное выполнение
insert to table -- c ошибкой
-- тут необходимо при ошибке откатить изменения выполнение хранимки 2
end;
При таком сценарии откатиться транзакция вся, целиком — как вы и хотите.

Если нужно избежать этого (т.е. в примере выше нужно, чтобы результат `хранимка2` остался),
то оберните ваш INSERT (любой потенциально падающий блок) в BEGIN ... EXCEPTION WHEN ... END; блок.

Также можно пользоваться SAVEPOINT-ами .
Они просто помечают "точки" в транзакции, до которых нужно откатываться если получено исключение после SAVEPOINT-а.

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

ОКТОГЕНp2.пропущено...
что изобретаешь, непрерывную бизнес-нумерацию? так блокируй всю таблицу, бери макс. и не связывай ее с рк, рано илм поздно нумерацию придетчя менять или иметь дубли или ...
Эта нумерация прямо для сборника "классика ошибок проектирования информационных систем".
У меня в биллинге (я в телекоме работаю международном) только некоторые страны страстно желают, чтобы нумерация счетов была непрерывной. Ох и муторное это дело! Но это одно поле, которое не входит в ключи.

Когда мне нужно было реализовать что-то подобное (на фрилансе) — непрерывная нумерация в рамках группы, я поступил так:
pg_advisory_lock(GROUP, _grp_id), где `GROUP` — просто номер, в виде макроса

SELECT coalesce(max(seq_num), 0)+1 INTO _seq FROM tab WHERE group_id=_grp_id

INSERT INTO tab (group_id, seq_num, ...) VALUES (_grp_id, _seq, ...);

pg_advisory_unlock(GROUP, _grp_id)

В целом, я бы пересмотрел вашу модель данных.

ОКТОГЕН,

Это EC (немцы, австрийцы). Вроде больше не напрягают с этим. Либо же саппорт научился "выкручиваться" без админов.