Для построение одной из систем не хватает следующего функционала. У пользователя должен быть набор прав на чтение данных в БД, кроме одной служебной хранимки - которая меняет данные. Может существует такая возможность какие то обходные пути? Ну или другой вариант когда сессия X читает данные но при этом могла бы их читать с учетом незакомиченных данных в транзакции сессии Y? Ну своего рода мапинг такой.Сейчас вариант есть менять на лету права но с точки зрения производительности и администрирования не подходит.

Объясню по другому. Есть БД в которой есть куча таблиц и хранимок. Хранимки некоторые меняют данные некоторые нет. Некоторая система понимает какие хранимки на изменение какие на чтение. Которые на чтение должны выполнятся на локальном сервере, а на изменение на другом. Что бы исключить ошибку идентификации(чтение - изменение) выдаются права только на чтение. То есть, если процедура ошибочно будет идентифицированна на чтение а произойдет изменение данных то возникнет ошибка. При все при этом возникает необходимость изменять данные из этой же сессии в этой базе но через "спец" канал - через специально выделенную хранимку.
Пока пришло такое решение в голову - меняем все таблицы на соответствующие вьюхи, а таблицы переименовываем на какое нибудь гарантированно уникальное значение например ТаблицаНовая =Таблица + 35645830. Ну а затем даем права на чтение вьюх и на использование спецхранимки на изменение. Правда проверить нужно, возможно при таком раскладе остальные хранимки смогут менять данные.

Еще забыл отметить что вьюхи должны быть доступны на чтение но при изменении должна происходить ошибка. (есть мысли еще через триггер ошибку генерить с проверкой канала изменений, в этом случае тогда вообще с правами заморачиваться не нужно)

Убегал в больницу, торопился извините за мой французский;) Вьюхи должны быть не обновляемые, такой термин будет думаю всем понятен.

To invm. Да пожалуй так красивее получится( в моем варианте надо парсить запросы и заменять названия таблиц, вьюхи то необновляемые). Спасибо, попробую.

Планируется создание универсальной системы прокси( для целей создания кластера) в которой нет возможности менять вызов запросов(можно минимально менять их на лету) и разделять их. Важно разделять чтение и запись и соответсвенно выполнять на различных нодах(это в общих чертах).