Как установить имя пользователя для триггера аудита Postgresql?

Question

Я использую триггер в PostgreSQL 8.2 для аудита изменений в таблице:

CREATE OR REPLACE FUNCTION update_issue_history() RETURNS trigger as $trig$ 
BEGIN 
     INSERT INTO issue_history (username, issueid) 
       VALUES ('fixed-username', OLD.issueid); 
     RETURN NULL; 
END; 
$trig$ LANGUAGE plpgsql; 

CREATE TRIGGER update_issue_history_trigger 
AFTER UPDATE ON issue 
     FOR EACH ROW EXECUTE PROCEDURE update_issue_history(); 

То, что я хочу сделать, это каким-то образом, чтобы обеспечить значение fixed-username в то время, когда я выполнить обновление. Это возможно? Если да, то как это сделать?

Answer 1

попробовать что-то вроде этого:

CREATE OR REPLACE FUNCTION update_issue_history() 
RETURNS trigger as $trig$ 
DECLARE 
     arg_username varchar; 
BEGIN 
     arg_username := TG_ARGV[0]; 
     INSERT INTO issue_history (username, issueid) 
      VALUES (arg_username, OLD.issueid); 
     RETURN NULL; 
END; 
$trig$ LANGUAGE plpgsql; 

CREATE TRIGGER update_issue_history_trigger 
AFTER UPDATE ON issue 
     FOR EACH ROW EXECUTE PROCEDURE update_issue_history('my username value'); 

Answer 2

Я не вижу способа сделать это, кроме как создавать временные таблицы и использовать EXECUTE в вашем триггере. Тем не менее, это будет иметь последствия для производительности. Лучшим вариантом может быть привязка к другой таблице где-то и вход в систему, кто регистрируется в/из идентификатора сеанса и внутреннего PID и ссылается на это?

Обратите внимание, что у вас нет другого способа получить информацию в инструкции по обновлению. Имейте в виду, что триггер может видеть только то, что доступно в API или в базе данных. Если вы хотите, чтобы триггер работал прозрачно, вы не можете ожидать передачи ему информации во время выполнения, чтобы у него не было доступа к другому.

Основной вопрос, который вы задаете, - «Как db знает, что там положить?» Когда вы решите метод, ответ должен быть прямолинейным, но нет бесплатных обедов.

Update

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

Существует два огромных ограничения с этим подходом. Во-первых, он создает много таблиц, и это в конечном итоге приводит к возможности обледенения.

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

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