> ну так я так и сделал

Нда. "Цените книги — источник фиги." ;) Вот что нужно использовать в таких случаях:

The FOR-IN-EXECUTE statement is another way to iterate over rows:

[ <<label>> ]
FOR target IN EXECUTE text_expression [ USING expression [, ... ] ] LOOP
    statements
END LOOP [ label ];

да, уже увидел. сейчас ещё раз попробую

получилось :(
обидно, ведь я уже так пробовал

И да, не писали бы Вы в стиле SELECT UNNEST(some_pks) — по-моему, использование set-returning functions в SELECT list сильно запутывает тех, кто потом будет это читать.

принял, спасибо

Если именно восстанавливать, то обычно есть специализированные средства (и зачастую это [нетривиальные] клиентские приложения).
А если нужна гетерогенная репликация — тоже есть специализированные средства, и они, в самом деле, могут хранить названия таблиц в базе данных.
В любом случае, ни к нормальному моделированию, ни к DR всё это не имеет отношения.

Трындец как плохо...

ну а как ещё сделаешь?

В таблице не должны храниться имена таблиц.

Нормально  и сделаешь.

Выгружай всё, да и всё.

я не знаю других решений

Почему нет? Для того же динамического SQL, особенно когда ко всем этим таблицам должна применяться одна и та же логика, — очень даже

Потому что нет, потому что невозможно эти данные обрабатывать с помощью SQL.

Если к таблицам должна применяться одна логика, таблица должна быть одна.

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

У меня был похожий на вышеописанный кейс, где нужно было по различным правилам собирать информацию о выручке в разрезе предоставляемых услуг, затем применять к полученному результату определенный набор преобразований, одинаковый для каждой из услуг, а затем сливать это все в одну таблицу. При этом собираться могут как все услуги разом, так и несколько (от 1 до N-1), а остальная часть таблицы должна оставаться без изменений.
Я, конечно, из-за сжатых сроков наворотил сначала все сплошным кодом с выполнением одних и тех же операция преобразования к данным таблицам, но процедура получилась на 5900 строк, кажется. Потом плюнул, обернул эти преобразования в prepared statement и вызывал ее через format с указанием названия временной таблицы для соответствующей услуги. В итоге процедура стала занимать всего лишь 2800 строк.

Вот при этих входных данных какие были более подходящие варианты, нежели тот, что я реализовал?

Собственно, ничего не мешало не явно задавать название временной таблицы, а записывать ее в отдельную временную таблицу и прогонять через цикл в ту же prepared statement, и это был точно такой же кейс, как и у молодого человека выше

Я лично понятия не имею, например. Вы в самом деле думаете, что это достаточно конкретное описание задачи? ;)

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