Início / dba / Perguntas / 161309
Accepted
David
Asked: 2017-01-18 04:07:32 +0800 CST

Renomeando a tabela e colocando uma view em seu lugar no Postgres

  • 772

Eu tenho uma tabela bem central em nosso banco de dados que é utilizada por uma série de aplicações, ela possui regras atreladas a ela, triggers e todas as dependências que você possa imaginar. Agora gostaria de modificar a tabela sem causar problemas nas dependências. Anteriormente, consegui fazer o seguinte, mas em um caso muito menos complexo:

alter table reconciliations rename to matches;
create view reconciliations as select * from matches;

O que isso significa é que agora eu poderia modificar a nova tabela "correspondências" e, por exemplo, adicionar uma coluna ou linhas, que não precisam ser apresentadas na exibição "reconciliações" (adicionando uma cláusula where para filtrá-las).

Estou no Postgres 9.5, então a visualização é atualizável automaticamente. Os testes iniciais mostram que não há problemas imediatos com isso, então estou fazendo esta pergunta para saber que tipo de problema devo procurar. O desempenho não é um grande problema.

postgresql migration

1 respostas

  1. Best Answer

    Se você fizer isso em produção, fique atento às instruções preparadas . Esses já foram analisados, reescritos (e o plano de consulta armazenado em cache). O efeito é ativado até que as instruções preparadas sejam desalocadas (o que pode levar muito tempo).

    Para verificar declarações preparadas (somente da mesma sessão!):

    TABLE pg_prepared_statements;

    O efeito também se estende às funções plpgsql que lidam com comandos SQL como instruções preparadas internamente.

    Normalmente, as instruções preparadas são forçadas a serem replanejadas após qualquer alteração nos objetos envolvidos. Mas suas ações contornam esse mecanismo de segurança.

    Além disso, a maioria das consultas continuará funcionando. Mas nem todos.

    Demonstração

    CREATE TEMP TABLE foo (id int);
INSERT INTO foo VALUES (4);
PREPARE x AS SELECT foo FROM foo WHERE id > $1;  -- uses row type

    Isso funciona:

    ALTER TABLE foo ADD COLUMN t text;
EXECUTE x(3);  -- automatically re-planned

    Mas isso não :

    ALTER TABLE foo RENAME TO foo1;
CREATE VIEW foo AS TABLE foo1;
ALTER TABLE foo1 ADD COLUMN t text;

EXECUTE x(3);  -- not re-planned!

    ERROR:  cached plan must not change result type

    O manual sobre PREPARE:

    Embora o ponto principal de uma instrução preparada seja evitar a análise de análise repetida e o planejamento da instrução, o PostgreSQL forçará a reanálise e o replanejamento da instrução antes de usá-la sempre que os objetos do banco de dados usados ​​na instrução tiverem sofrido alterações de definição (DDL). desde o uso anterior da instrução preparada. Além disso, se o valor de search_pathmudar de um uso para outro, a instrução será reanalisada usando o novosearch_path. (Este último comportamento é novo no PostgreSQL 9.3.) Essas regras fazem uso de uma instrução preparada semanticamente quase equivalente a reenviar o mesmo texto de consulta repetidamente, mas com um benefício de desempenho se nenhuma definição de objeto for alterada, especialmente se o melhor plano permanece o mesmo em todos os usos. Um exemplo de caso em que a equivalência semântica não é perfeita é que, se a instrução se referir a uma tabela por um nome não qualificado e, em seguida, uma nova tabela com o mesmo nome for criada em um esquema que aparece anteriormente no search_path, nenhuma reanálise automática ocorrerá, pois nenhum objeto usado na instrução foi alterado. No entanto, se alguma outra alteração forçar uma nova análise, a nova tabela será referenciada em usos subsequentes.

    O exemplo acima é outro em que a "equivalência semântica não é perfeita" .

    • 6

relate perguntas