У нас в проекте _слишком_ много pl/sql-кода (легаси почти с 2000 года).
Начитавшись о всяких подводных камнях решили не "переводить", а "выстроить" новый проект, и попутно избавиться от костылей и всякого.

По оракловым фичам:
- от автономных транзакций удалось отказаться без потерь (внушив себе, что автономки сами по себе - костыль.. хотя, конечно, с ними удобнее)
- временные таблицы в PG - их лучше не использовать, лучше создавать unlogged таблицы и эмулировать доступность данных в них по аналогии с временными в оракле
- вместо пакетов использовать схемы
- вместо глобальных переменных - таблицы и контекстные переменные
- джобы заменяются pgagent'ом
- utl_xx, dbms_xx - внешними сервисами

most23,

похоже что нет. Я долго искал, много чего перепробовал, всё оно к разработке подходит с какого-то другого боку.

Тем не менее, я остановился на двух утилитах.
1. Это dbeaver, у него есть бесплатная редакция. Такой, вполне себе простенький тул, чем-то мне напомнил SQLTools для ораклы.

2. datagrip, там есть студенческие лицензии, либо для индивидуального девелопера не так уж и дорого, при этом у него куча настроек (вполне под себя можно настроить) и куча плюшек, типа прозрачной интеграции с GIT, интуитивное ведение проекта (когда проект - это каталог в файловой системе, и дальше все файлы и подкаталоги видны) и много всякого именно для разработки (закладки, избранное, TODO..).
В ПГ нет пакетов как в оракле, но можно функции объединять в схемы, и в этом случае все функции схемы я сохраняю в единый файл (а не каждую функцию в отдельный файл) - датагрип умеет в отдельной панели отображать структуру файла (с сортировкой по именам) для быстрой навигации.. вполне юзабельно.
Но надо быть готовым к тому, что придётся потратить время на настройку. По началу датагрип тормозной (постоянно парсит исходники, у него куча помощников надоедливых), он кэширует метаданные (что мешает при параллельной разработке и приходится этот кэш сбрасывать), автоматически сохраняет _все_ файлы не спрашивая...

Да, ещё такие "беды" в ПГ есть (я относительно 12й версии ПГ пишу, с другими не работал).

1. ПГ не умеет строить зависимости по процедурам. Зависимости видны только по форейн-ключам таблиц, по вьюхам и триггерам.

2. Процедурный код при "компиляции" проверяется только на синтаксис. Т.е. оно даже не компилируется... хотя утверждать не буду, возможно какое-то дерево исполнения строится заранее (а может и на лету).
Ошибки (ну например банальная опечатка в коде) будут при исполнении, причём только если исполнение дошло до этой строки (ну if-then-else блоки).
Поэтому каждую функцию надо тестировать. Ну и датагрип тут помогает, он опечатки подсвечивает (да, рефакторинг в нём достаточно удобный).

3. Для вьюх зависимости ПГ строит, но они больше мешают, чем помогают. Например, если поверх таблицы есть вью, то изменить тип поля в столбце (или переименовать столбец, что нормально именно на стадии черновой разработки) уже становится проблемой - все зависимые представления надо будет удалять, а потом создавать заново. Поэтому надо сразу отделять таблицы от всего остального, а всё остальное хранить отдельно и в репозитории.

Вообще следуют сразу строго настрого запретить разработчикам менять код непосредственно в БД, т.е. мы делаем так:
- сначала создаётся файл (со вьюхой, или группой вьюх, или процедурами)
- файл накатывается на БД для разработки (я забил на общую БД, развернул у себя на локальном компе, это тупо быстрее), тестируется и т.п.
- файл комитится в GIT
- из GIT'а (пока ещё не сделали, но будет, что-то типа git-flow или пайплайны) оно автоматически накатывается на отдельный инстанс и там тестируется

muller,

Да, простой тест:



функция test.f1() существует, поэтому вызов select test.main(true) отработает, второй функции нет - вызов select test.main(false) завершится ошибкой:



С другой стороны, я вижу в этом возможность обхода отсутствия условной компиляции. В Oracle оно есть:


Используем для реализации, так сказать, client specific логики.

Ну а в целом, такие особенности вынуждают писать код более прямолинейным и чистым... и практика показывает, что это возможно, но требует бОльших усилий (особенно тяжело новичкам).

Насчёт тестирования - использую такой подход, при котором не создаётся больших (по кол-ву кода) процедур. Если процедура делает много чего, то каждый кусочек выделяется в отдельную процедуру, которая и тестируется. При написании кода с нуля, тут ничего такого нет, только рутина.
Ежели брать Oracle легаси (у нас до дури plsql-кода с использованием сомнительных практик)... я даже не знаю, отказался я от этой идеи.

Кстати недавно наткнулся на такое (при работе со структурными типами). Вот так писать нельзя (PG 12):


вместо этого надо:


Это работает как plpgsql, так и в sql.
см. здесь

Да, и ещё одна особенность: null в уникальном индексе не работает. Т.е. если хоть одно из полей составного индекса из null, то уникальность не работает.
Варианты обхода:
а) использовать where
б) приводить к not null с помощью coalesce

Эта проблема уже несколько раз на этом форме поднималась, например вот:
Как создать уникальный составной индекс, который может содержать null значение