PostgreSQL и / или SQL Server альтернативы Oracle SYS_CONTEXT

Question

Пользуясь БД Oracle некоторое время, я привык использовать контекст приложения БД Oracle для реализации ограничений доступа. Проще говоря, при входе в систему вызывается процедура, которая помещает данные пользователя в контекст приложения Oracle следующим образом:

DBMS_SESSION.SET_CONTEXT('context_name', 'user_id', user_id);

Тогда доступ может быть принудительно создан путем создания представлений, которые будут выглядеть в контексте, чтобы определить, какие строки может видеть пользователь, например:

CREATE VIEW users_vw AS 
SELECT *
  FROM users
 WHERE user_id = SYS_CONTEXT('context_name', 'user_id');

Я перешел из Oracle и использую PostgreSQL для личных проектов, а также SQL Server 2000 и 2008 на работе. Может кто-нибудь сказать мне, есть ли соответствующие возможности, которые предлагают PostgreSQL или SQL Server?

Answer 1

В PostgreSQL, возможно, вы могли бы обойтись с SECURITY DEFINER -функциями, действующими для текущего пользователя? Документировано здесь: http://www.postgresql.org/docs/8.4/static/sql-createfunction.html

Edit:

plperl может использоваться для переменных сеанса . Существуют и другие альтернативы (см. Ссылку в комментарии), но plperl - самый простой из них.

Answer 2

Вы можете использовать Postgres 'SET или SET LOCAL команду для эмуляции Oracle SET_CONTEXT(), например. следующим образом:

SET LOCAL audit.AUDIT_USER = 'whatever-you-like';
-- alternative:
SELECT set_config('audit.AUDIT_USER', 'whatever-you-like', true);

Затем вы можете получить это значение, используя current_setting () :

SELECT current_setting('audit.AUDIT_USER', true);

(Второй аргумент, true, позволит избежать исключения, если перед запросом параметр не был SET, а вместо него вернуть NULL. Аргумент был введен в Postgres 9.6, см. Этот вопрос для , как сделать это в Postgres 9.1 + .)

Я также создал демонстрационный механизм механизма аудита , использующий SET LOCAL и current_setting() для реализации аудита на уровне БД с данными, предоставленными приложением.

Наконец, некоторые важные детали, упомянутые в документации, выделено мной:

Эффекты SET LOCAL действуют только до конца текущей транзакции , независимо от того, зафиксированы они или нет.

(Напротив, значения, установленные с SET, имеют сессионную область.)

Answer 3

Если вы будете использовать pl / perl (или pl / python, если я правильно помню), вы получите переменные сессии бесплатно.

В противном случае - при использовании plpgsql - вы можете использовать GUC для хранения своих настроек и использовать их практически таким же образом.