Значит изменила память :) не за компом сейчас

Значит, у вас антипаттерн "общая база".

Можно сделать View и запросы на чтение делать через них. Или функции-возвращающие-таблицы

почему антипаттерн? ну есть архитекторы, админы базы. А есть юзеры. Юзеры пишут к базе запросы на выборку инфы. Если столбец таблицы в базе переименовывается, то нужно оповестить об этом юзеров, чтобы они отредактировали свои скрипты. А мне хочется, чтобы это автоматически происходило

Для очень больших объектов используется утилита vacuumlo: https://postgrespro.ru/docs/postgresql/11/vacuumlo

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

Частая проблема, на самом деле. Тут дело не в архитектуре даже, а в том, что разработка не всегда бегает и рассказывает всем, что в базе что-то поменялось.

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

CREATE OR REPLACE FUNCTION public.find_customers_for_imitation(ids bigint[])

Почему ids не видит как параметр?

В аналитике короче частая боль))

вот решение нашел: https://www.red-gate.com/hub/product-learning/sql-source-control/github-and-sql-source-control
но платное

и для SQL SERVER

В такой постановке задача же явно не имеет решения, нет?
Допустим, они хранят свои запросы в текстовых файлах... и что бы кто-то ни менял в базе, они же "магически" не изменятся. ;)
Поэтому на практике — либо views, либо functions, либо тестирование и т.д.

В общем случае решения нет. Например, если поле уехало в отдельную таблицу-справочник, то робот не осилит поправить запрос

Отдавать такие операции на откуп автоматике стрёмно, кмк. Лучше просто алертить

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

CREATE OR REPLACE FUNCTION public.find_customers_for_imitation(ids bigint[])

А почему Вы не показываете функцию и ошибку целиком?

Или бывает, что после автопереименования получается ambiguous column name

CREATE OR REPLACE FUNCTION public.find_customers_for_imitation(ids bigint[])
  RETURNS setof contacts_count
  LANGUAGE plpgsql
AS $function$
  begin
    create or replace view contacts_count as 
    select contacts.user_id, count(contacts.user_id) 
    from contacts 
      where contacts.user_id = any(ids)
    group by contacts.user_id;
  END;
SQL

Error [42703]: ERROR: column "ids" does not exist
 Подсказка: Perhaps you meant to reference the column "contacts.id".
 Где: PL/pgSQL function find_customers_for_imitation(bigint[]) line 3 at SQL statement
 ERROR: column "ids" does not exist
 Подсказка: Perhaps you meant to reference the column "contacts.id".
 Где: PL/pgSQL function find_customers_for_imitation(bigint[]) line 3 at SQL statement
 ERROR: column "ids" does not exist
 Подсказка: Perhaps you meant to reference the column "contacts.id".
 Где: PL/pgSQL function find_customers_for_imitation(bigint[]) line 3 at SQL statement

У вас же база изменяется через миграции? Вот добавьте туда какой-нибудь хук, который будет уведомлять тогда, когда новая миграция заезжает

CREATE OR REPLACE FUNCTION public.find_customers_for_imitation(ids bigint[])
  RETURNS setof contacts_count
  LANGUAGE plpgsql
AS $function$
  begin
    create or replace view contacts_count as 
    select contacts.user_id, count(contacts.user_id) 
    from contacts 
      where contacts.user_id = any(ids)
    group by contacts.user_id;
  END;
SQL

Потому что CREATE не параметризуются в принципе (а вообще функция выглядит как-то очень странно — зачем view пересоздавать при каждом вызове, что это вообще за подход?!).
Я даже не хочу подсказывать, как тут дальше выстрелить себе в ногу, если честно. ;(