> > Ладно, каков вывод делать? CURRENT_TABLE - > > отказать на принципиальном уровне? > > Прям сразу и в обидки :)
На каком основании такой вывод? :) Я абсолютно ровно отношусь к этой проблеме. Обходной путь есть, просто с CURRENT_TABLE, как-то красивше было бы, если можно так выразиться. Тем более с учетом _уже_ размноженных CURRENT_XXXXXX с информацией об "окружении". В этом контексте и возникла реинкарнация вопроса о некоем CURRENT_TABLE, который поднимался уже не один раз. Т.к. по результатам обсуждения больше просматривается "нет", чем "да", то резюмирующий вопрос имеет отрицательный смысловой оттенок. > Вишь - Чапаи молчат, знач думают. Печёнка > чует, что где-то должен быть с неё какой-то толк. Но вот где и какой - > придумать не может. Безопасный COPY-PASTE кода триггеров :))) Кстати, не совсем смешно, а даже очень и очень (с) :) Т.к. именно ошибки, порождаемые этой технологией наиболее трудны в своем выявлении... > То, что тебя к ней сподвигло, динамика в > SQL-выражениях в триггере - прямой путь к тормозам. Да нет никакой динамики :) Я просто хотел (иметь возможность) оформить _одинаковое_ тело для всех искомых триггеров наиболее простым способом, не прописывая _в каждом_ из них руками имя таблицы-овнера аки строковую константу в кавычках, а просто элегантно указать CURRENT_TABLE. Другими словами, код может быть более читабельным и "переносимым" (между триггерами).
