это вопрос про доверенный и недоверенный https://postgrespro.ru/docs/postgresql/12/plperl-trusted

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

да, согласен, упустил из виду(( спасибо что обратили внимание

Я просто на это напарывался в двух местах довольно таки недавно, и это было ОЧЕНЬ БОЛЬНО

просто у нас есть несколько сервисов, которые работают с одной БД и могут менять в ней данные, причем изменение данных должно тригериться в конечный сервис и там обрабатываться. Вот думаю как это побыстрее сделать с минимальными усилиями. Можно было бы прицепить на все какой нить eventbus, но время поджимает

а такой вариант может прокатить? так как pl/python является недоверенным языком (спасибо @RPG18_87 за уточнение) и по сути не ограничен в работе с файловой системой, то при срабатывании триггера создается отдельный файл с данными, который обрабатывается и очищается сторонним приложением. Оверхед вроде не должен быть сильно большим. Какие могут быть проблемы в этом случае?

хотя полагаю да, такие же проблемы как и с запросами, если fs очень сильно занята, опять проблема с транзакциями(

Если костылять, то можно взять https://postgrespro.ru/docs/postgresql/12/logicaldecoding

Пример использования на Go https://github.com/hasura/pgdeltastream

Вообще ходить из бд на внешние задачи лучше через messagequery, ИМХО

Кинул в очередь сообщение оно дальше асинхронно поехало

прям как датасаентисты 7го дня

потому, что курс неделю

у меня есть 2 сервера на пг12, с мастера через walg летят логи сразу в бэкап и на standby слейв. как лучше всего сделать фаиловер? там же флажковые файлы надо подергивать чтобы слейв переключить в нормальный режим

напомнило название книги "Семь баз данных за семь недель"

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

Попахивает весьма кривой архитектурой, однако! Когда разным прикладам, пользующимся одной базой, надо ещё дополнительно что-то куда-то слать.
В любом случае, взаимодействие между внешними сервисами - зто уровень приклада, никак не СУБД, потому что лютая асинхронщина, и вот это вот фсйо. Либо, если  уж очень хочется упороться по самые помидоры, то pgq (1, база: https://github.com/pgq/pgq; дыва - ПГ-вики: https://wiki.postgresql.org/wiki/PGQ_Tutorial; тры - хабр: https://habr.com/ru/post/483014/; ) - путь для сильных духом и любителей, например, разного, "интересного".

Не проще будет подцепить какой-нибудь debezium+kafka, а на той стороне ловить события?

Debezium, конечно, хорошо. Только "та сторона" должна быть готова к тому, что в определенный момент пойдет полный инит данных.

Насчет архитектуры согласен, поэтому сейчас и занимаемся глобальным рефакторингом. В данном случае речь про легаси. Просто продакты, как обычно, им надо фичу, срочно, вот и приходится костылять((