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 значение