ТриггерЭто конечно вариант :)
Это не "конечно вариант", а "правильный вариант".

Триггер но может есть что-то типа dictionary_obj_name для ddl-триггера?
И какой в этом смысл? "Таблица, на которой повешен триггер" - идеологическая константа. Для написания кода руками она нафиг не нужна, для всяких автогенерируемых стандартных прибамбасов ее тривиально засунуть именно в виде константы.

RA\/ENВоросы?
1. Покажете то же самое в нормальной технологической цепочке, а не на тестовом примере? Нормальная цепочка - это в смысле "проектировщик переименовывает таблицу в CASE инструменте..."

RA\/EN softwarer1. Покажете то же самое в нормальной технологической цепочке, .... (1)Тривиально - попытки поиметь нечто вроде секционированной таблицы на SE. .... (2)
(2) - признаться, не выглядит ответом на (1). Вы пытаетесь ответить "когда такая задача может возникнуть", а я прошу - нормальную технологическую цепочку, о чем Вы не сказали ни слова.

Hint: "нормальная технологическая цепочка" подразумевает в том числе те или иные гарантии валидности автоматически генерируемых объектов. Скажем, в базе будет висеть DDL-триггер, который отловит Ваш rename и инициирует пересоздание триггера.

RA\/ENО критериях "нормальности" можно спорить до хрипоты...
О полном списке - безусловно. Но вряд ли Вы будете спорить с тем, что надежность входит в них под одним из первых номеров.

RA\/ENЯ считаю, что наворачивать кодогенерацию там, где достаточно получить информацию стандартными средствами Oracle, есть пустая трата времени разработчиков, тестеров и сопровожденцев.

[src oracle]SQL> create or replace trigger trig1 before insert on toredo
2 begin dbms_output.put_line(dbms_utility.format_call_stack); end;
3 /

Trigger created

SQL> insert into toredo values(1);

----- PL/SQL Call Stack -----
object line object
handle number name
==>222120FC 1 K.TRIG1
Cчитать, безусловно, можно что угодно. Вот обосновать, что одна кодогенерация (которая рассует по десяти-ста-десяти тысячам таблиц триггер с парсингом стека) чем-то кардинально отличается от другой кодогенерации (которая рассует тот же триггер с константой) - оно как-то сложнее. Обосновать пустую трату времени разработчиков на константы по сравнению с пустой тратой времени разработчиков на парсинг - тоже не совсем тривиально.

RA\/ENА где я говорил, что предполагаю кодогенерацию? Я ее не предполагаю.
Тогда Вы ее как-то странно не предполагаете. Вы почему-то в одном случае не предполагаете, а в другом считаете, что она будет.

RA\/ENИ вообще это форум по Oracle, а не проектированию :)
То есть Вы переходите к версии "это может понадобиться при кривом проектировании"?

RA\/ENЛадно, вот второй пример - из "была ли функция вызвана из триггера, и, если да, то на какой он таблице?" Вопрос практически эквивалентен авторскому. Предлагаете сквозную передачу параметров через десяток функций заложить?
Этот пример в нормальной практике работы существовать не может и не должен. Функции должно быть все равно, откуда ее вызвали; если не все равно, если какие-то ее действия этим определяются, это - ошибка проектирования. В некоторых случаях может понадобиться понятие контекста - "правызывающий" устанавливает некоторое состояние, правызываемый им пользуется.

Я могу назвать единственную ситуацию, когда более-менее интересен ответ на приведенный Вами вопрос. Но я решаю ее несколько проще:


SYWell, I do not know what is идеологическая константа, but I do know tables can be renamed :)
Безусловно, can. И что из этого следует, если мы говорим о реальном производственном процессе? Переименование таблицы - очень редкая операция относительно других alter-ов, которые также вызывают необходимость менять навешенные триггера. Поэтому придумав способ защищаться только и исключительно от rename, мы практически зря потратим время, увеличив общую надежность кода на очень малую величину. А любой нормальный способ, контролирующий alter-ы вообще, будет работать и для rename тоже - убирая тем самым необходимость во всей этой дополнительной шелухе.

Что же касается идеологической константы.... ну вот скажем число "пи" - как Вы полагаете, константа или нет? Хотя мы оба знаем, что в очередной версии софта оно can be changed - например, может потребоваться повысить ему разрядность.

P.S. Помимо прочего, у меня действует рефлекс на минимизацию обращений к data dictionary - это часто здорово тормозит работу.