Между прочим с правилами на SELECT не все так уж здорово.
Прежде всего там возможен только INSTEAD да и то выполнить группу запросов в "( )" в 7.3.x нельзя. Насчет 7.4 ничего не скажу -
я его пререлиз только скачал и еще не устанавливал.

Чуть конкретнее опиши чего ты хочешь, впрочем думаю что правило на
SELECT модифицирующее результаты вполне справиться с этой задачей.
Нечто похожее уже было.

Решить таки можно, только спать охота..... 8(
Впрочем попробуем.
alter table radreply rename to tb_radreply;
create or replace function ftb_radreply() returns SETOF tb_radreply as
'
/* Тут воротишь всякие поправки,тарифы,фискал и прочая
*/
select * from tb_radreply;-- ну и возвращаеш сет своей таблицы
' LANGUAGE SQL;
А дальше малехо камамлы....
делаем вьюшку.
create or replace view radreply as select * from tb_brokers limit 0;
пресловутое правило на select только так как оно не понимает группу запросов в () подставляем функцию.
Название строго такое как написано.
create or replace
rule "_RETURN" as on
SELECT to resellrs
do INSTEAD
select * from ftb_radreply() as set1;
Название правил на insert и update произвольное.
create or replace
rule radreply_ins as on
INSERT to resellrs
do INSTEAD
insert into tb_radreply
(UserName , дальше список колонок ........)
values
(NEW.UserName , дальше список значений обрати внимание на NEW. .......);
с Update тоже самое - ну появляется на сцене префикс OLD.
Хотя update tebe как раз и не нужен!
Имхо получается неплохо - главное что нужно смотреть - чтоб небыло
цикличиских вызовов правил.... Ну про это есть в доке.

Перечитал пост и тут же нашел ляп:
Вьюшку правильно делать так.
create or replace view radreply as select * from tb_radreply limit 0;

Да это замедляет - ну а как ты хотел? Приведи примеры из других SQL - диалектов.
rule "_RETURN" as on
SELECT to radreply
do INSTEAD
select * from ftb_radreply() as set1;
Это просто правило определяющее, что при SELECT-е из
radreply -ЗАМЕСТО выборки из таблицы - будет вызвана
функция ftb_radreply(), кстати псевдоним as set1 наверное излишен -
все равно там Множество возвращается.
Теперь про create or replace view radreply as select * from tb_radreply limit 0;
Да - это быстрее чем описывать заново кучу полей. И вьюшка получается -
точное зеркало.
limit 0 - понимаешь ли если ты напишешь тут например напишешь '1<>1' - так
когда-то я делал 8) - получишь тот же результат - до создания правила
"_RETURN" - это будет вечно пустая вьюшка ну а после.... она будет
связана с нашей функцией и предыдущий select определявший вьюшку затрется. Кстати наверное можно сделать вьюшку как select * from ftb_radreply() as set1; разницв никакой не будет
Насчет тормозов - все будет зависить от твоей функции рачета и я уверен что триггер тут срабатывал бы с примерно той же потерей скорости.

Супер подхода тут ожидать не приходиться - тем более что для M$ SQl
я пока решения в доке по 2K не увидел.
События для триггеры у них теже, а вот правил кстати не было никогда -
так что ой-ей.
Я на подобном методе уже запустил сбор статистики работы операторов.
Особо это их не отяготило. Хотя некоторые вещи я реализовать пока не смог.