Dos documentos - 37.3.1.1. "Uma primeira regra passo a passo"
CREATE TABLE shoelace_log (
sl_name text, -- shoelace changed
sl_avail integer, -- new available value
log_who text, -- who did it
log_when timestamp -- when
);
CREATE RULE log_shoelace AS ON UPDATE TO shoelace_data
WHERE NEW.sl_avail <> OLD.sl_avail
DO INSERT INTO shoelace_log VALUES (
NEW.sl_name,
NEW.sl_avail,
current_user,
current_timestamp
);
Agora alguém faz:
(1) UPDATE shoelace_data SET sl_avail = 6 WHERE sl_name = 'sl7';
E o analisador gera essa consulta adicional
(2) INSERT INTO shoelace_log VALUES (
shoelace_data.sl_name, 6,
current_user, current_timestamp )
FROM shoelace_data
WHERE 6 <> shoelace_data.sl_avail
AND shoelace_data.sl_name = 'sl7';
A questão é: existem ferramentas para dizer como a consulta (1) é reescrita em (1) + (2)?
Não há uma maneira direta de ver uma representação SQL da consulta reescrita, porque a reescrita ocorre em uma representação de árvore interna e não é fácil transformá-la novamente em SQL. O mais próximo é ativar o parâmetro de configuração
debug_print_rewritten
, que imprime uma representação desse formato de árvore interna no log do servidor. Se você usar isso em conjunto com as configuraçõesdebug_print_parse
edebug_print_plan
(e possivelmentedebug_pretty_print
), poderá ver como a consulta é transformada em vários estágios. O formato não é fácil de ler, mas se você estiver interessado em aprender os detalhes disso, provavelmente valerá a pena.