Хмм... а какие у Вас есть альтернативы?
По-моему, аккуратное использование sed решит эту задачу с высокой вероятностью. ;)

Читаю https://www.sqlstyle.guide/ru/#cтолбцы. Пишут "По возможности не используйте id в качестве первичного идентификатора таблицы". Что имеется в виду, что id как primary key использовать нежелательно? Почему?

Да, с альтернативами плохо, разве что copy to использовать

Всем привет

ПОдскажите пожалуйста как создать расширение oracle_fdw?

всмысле его нет)

https://github.com/laurenz/oracle_fdw не?

Схему же всё равно придётся переносить...
И если Вы готовы на copy "вручную", почему уж не просто INSERT/SELECT (зачем вообще вовлекать в это дело экспорт/импорт данных)?
А большие объёмы — это сколько, кстати?
Я к тому, что, может, стоит сделать как можно проще, и подождать подольше, чем "выкручиваться"? ;)

Схему переносить не нужно, интересуют только данные. Данных много от 1Гб до десятков Гб. Операцию хотим поставить на поток.

Эээ... что? Вы данные куда собираетесь копировать, если не в таблицы? ;)

> Данных много от 1Гб до десятков Гб.

Это называется очень мало по нынешним временам, just FYI.

Конечно в таблицы, но в другую базу и как вариант в другую схему в другой подсети

Пока вижу решение так:
Выгрузку таблицы в CSV и последующее копирование\восстановление в другую базу\схему

Для этого можно dblink использовать, к примеру.

Была у него только мерзкая манера в целевой базе транзакцию открывать и держать от отключения.

Мысль хорошая, но боюсь безопасники зарежут)

Да, тогда (если нет варианта FDW и т.п.) Вам понадобится экспорт/импорт (я думал, Вам нужно внутри одной БД).

> Выгрузку таблицы в CSV и последующее копирование\восстановление в другую базу\схему

Т.е. нужные пустые таблицы в нужной схеме у Вас в целевой базе уже есть?

Да, все верно, пустые таблицы есть. Вариант с FDW не подойдет(

The supported Oracle server versions depend on the used client version (see the Oracle Client/Server Interoperability Matrix in Oracle Support document 207303.1). PostgreSQL and Oracle need to have the same architecture. For example, you cannot have 32-bit software for the one and 64-bit software for the other.

Т,е. еще инсталить и клиента?

Если "на поток" и нужно 100% надёжно, придётся написать что-то своё, наверное — подходящих опций pg_dump / pg_restore я что-то не вижу. :(
Есть вариант data-only pg_dump + sed... но так можно дозаменяться, т.е. заменить строку-название схемы в самих данных (хоть и с крайне низкой вероятностью). ;)

Кстати, почему бы (раз у Вас есть схема в целевой базе), не "потанцевать" с переименованиями схем?
Т.е. временно целевую переименовать под источник, потом обратно?