У меня было объяснение, почему ora2pg теряет внешние ключи при переносе схемы в PostgreSQL. Я его опроверг, придумал новое и опроверг ещё раз. Настоящая причина оказалась в одной проверке exists() в Perl-коде, а чинится всё одной строкой в конфиге.

ora2pg переносит схему с Oracle на PostgreSQL, и в целом переносит хорошо. Интересное начинается там, где он чего-то не осилил: он не падает и не ругается, а молча делает не то.

Процедура с AUTHID исчезает из вывода целиком, без ошибки и без строки в логе. TO_DATE с форматом RR молча возвращает 1 год до нашей эры. LONG RAW превращается в text, хотя сам ora2pg документирует bytea. Обработчик исключений после конвертации ловит SQLSTATE, которого PostgreSQL не возбуждает никогда.

Двадцать таких мест, все проверены на реальном ora2pg 25.0 и живом PostgreSQL 16, по каждому написано чем чинить.

Работаю в конторе, которая обслуживает госзаказчиков, и последние месяцы у меня одна большая головная боль: перевод старой оракловой схемы на Postgres Pro. Контур закрытый, интернета нет, лицензии на Enterprise нет, проприетарной ora2pgpro тоже нет. То есть из автоматики только опенсорсный ora2pg, и всё.

Штука рабочая, кто пользовался, тот знает. По разным оценкам тянет процентов восемьдесят перевода PL/SQL в PL/pgSQL. Для инструмента, который пилят несколько человек в свободное время против СУБД с тридцатилетней историей, это вообще‑то дофига )

Схема не маленькая, под сотню пакетов и триггеров, плюс куча legacy, которое живёт ещё с нулевых. И когда я первый раз прогнал её через ora2pg и увидел зелёный SHOW_REPORT, я на секунду выдохнул. Рано выдохнул, как выяснилось;)

В итоге доканали меня не эти восемьдесят процентов, а оставшиеся двадцать. И не количеством. А тем, что они не падают в момент конвертации, а спокойно ждут, пока код доедет до прода.