user1241Что до практических примеров - то в некоторых случаях обогащение в ETL вполне можно рассматривать как таковой.
Желательно более полный пример, пусть с ETL, с тем как это используется.
[/quot]
1. Генерация суррогатного ключа по правилам чуть более сложным, чем sequence
2. Обогащение кодом словарной статьи (в ассоциативном массиве держим словари) - снижает количество join в запросе, что при параллельном исполнении на большом объеме может давать профит за счет уменьшения использования temp под буферизацию
3. [телеком] Обогащение записи о соединении кодом города (максимально полное соответствие при переменной длине префикса) - неплохо решается на ассоциативном массиве зоновой разбивки.
Elic что-то подобное говорил про номера банковских карт (BIN?).

user1241И желательно, где нет выше описанной проблемы, и код, который не было бы лучше переписать через bulk collect / forall.

Описанной проблемы нет, если следовать правилу явного перечисления полей - как в курсоре, так и в insert.
Переписывание под bulk collect не всегда оправдано ввиду автоматического "переписывания под bulk collect" курсорных циклов на дефолтном уровне оптимизации pl/sql в современных версиях rdbms.

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