
Qual a primeira ação do DBA para poder trabalhar com a view pg_stat_statements?
20 de outubro de 2025Normalmente, para atender demandas que envolvam lógicas de negócios complexas que interajam com o banco de dados, é necessária a criação de várias instruções SQL que acabam trocando informação entre elas. Ou seja, são interdependentes pois uma depende dos resultados de outra para prosseguir com sua execução.
Nesse caso, a execução dessas múltiplas instruções acabam gerando um alto fluxo de dados entre o banco de dados e a aplicação, que, por sua vez, impactam no desempenho desses sistemas devido ao grande número de pacotes de dados transferidos pela rede. Como solução para esse tipo de problema, existe a possibilidade de utilizar procedimentos armazenados ou funções, que são executados diretamente no banco de dados.
O PostgreSQL utiliza o SQL, que é uma linguagem de domínio específico comum para bancos de dados relacionais, como linguagem de consulta padrão.
No entanto, ele possui sua própria linguagem procedural, semelhante ao que ocorre com outros bancos de dados, conhecida como PL/pgSQL, que oferece uma gama de recursos poderosos como recursos de programação orientada a objetos, com a capacidade de definir operadores e tipos personalizados, bem como agregados personalizados, criar funções, procedimentos armazenados e gatilhos que melhorarão o desempenho, reduzindo as múltiplas iterações nos bancos de dados. Suporta, também, estruturas de controle, tratamento de exceções, variáveis, loops e instruções condicionais, facilitando o desenvolvimento de aplicativos complexos de banco de dados de uma forma mais eficiente.
O PostgreSQL também suporta outras linguagens procedurais, como PL/Java, PLV8, PL/Python, PL/Perl, etc, mas, diferentemente dessas linguagens, o PL/pgSQL está intrinsecamente ligado à engine do banco, garantindo um desempenho otimizado e uma adaptação perfeita para a construção da lógica de negócios no lado servidor da aplicação.
Assim como as demais linguagens, o PL/pgSQL também é uma extensão. No entanto, ela é instalada por padrão no servidor PostgreSQL, não necessitando de nenhuma ação por parte do DBA, para que possa ser utilizada.
O erro que trouxemos (“ERROR: language "plpgsql" does not exist”), e que deu origem a este artigo, indica que, por alguma razão, esta extensão não está presente no database utilizado para criar a função ou o procedimento armazenado (stored procedure).
Na imagem abaixo, podemos ver que a extensão não existe no database postgres, mas se encontra presente no database teste.
Aqui também podemos perceber uma diferença importante com relação às demais extensões: a PL/pgSQL (plpgsql) é habilitada automaticamente com a criação do database.

Assim, tudo o que precisamos fazer é habilitar a extensão no database onde será criada a função ou a stored procedure, como exemplificado abaixo.

Não se trata, portanto, de um problema tão sério a extensão não estar habilitada no database. Basta habilitá-la para que tudo possa voltar à normalidade.
O que é preciso observar aqui é “quem excluiu essa extensão de dentro do database” pois essa pessoa, pode estar com mais permissões do que o necessário, o que acaba colocando em risco a integridade do database de dos dados nele armazenados.
É isso aí, pessoal. Nos vemos no próximo artigo!





