Estritamente falando, o termo "procedimentos armazenados" aponta para procedimentos SQL no Postgres, introduzidos no Postgres 11.
Também existem funções , fazendo quase, mas não exatamente o mesmo, e essas existem desde o início.
Funções com LANGUAGE sqlsão basicamente apenas arquivos em lote com comandos SQL simples em um wrapper de função (e, portanto, atômico, sempre executado dentro de uma única transação), aceitando parâmetros. Todas as instruções em uma função SQL são planejadas de uma vez , o que é sutilmente diferente de executar uma instrução após a outra e pode afetar a ordem na qual os bloqueios são executados.
Para qualquer coisa mais, a linguagem mais madura é PL / pgSQL ( LANGUAGE plpgsql). Funciona bem e foi aprimorado a cada versão na última década, mas serve melhor como cola para comandos SQL. Não se destina a cálculos pesados (exceto com comandos SQL).
As funções PL / pgSQL executam consultas como instruções preparadas . A reutilização de planos de consulta em cache reduz algumas sobrecargas de planejamento e as torna um pouco mais rápidas que as instruções SQL equivalentes, o que pode ser um efeito perceptível dependendo das circunstâncias. Também pode ter efeitos colaterais, como nesta pergunta relacionada:
Isso traz as vantagens e desvantagens das declarações preparadas - conforme discutido no manual . Para consultas sobre tabelas com distribuição de dados irregular e parâmetros variáveis SQL dinâmica com EXECUTEpode ter um melhor desempenho quando o ganho de um plano de execução otimizado para o parâmetro dado (s) supera o custo de re-planejamento.
Desde o Postgres 9.2, os planos de execução genéricos ainda são armazenados em cache para a sessão, mas, citando o manual :
Isso ocorre imediatamente para instruções preparadas sem parâmetros; caso contrário, ocorrerá somente após cinco ou mais execuções produzirem planos cuja média de custo estimada (incluindo despesas gerais de planejamento) seja mais cara que a estimativa genérica de custo planejado.
Nós obtemos o melhor dos dois mundos na maioria das vezes (menos alguns custos adicionais) sem (ab) usar EXECUTE. Detalhes em O que há de novo no PostgreSQL 9.2 do PostgreSQL Wiki .
O Postgres 12 apresenta a variável de servidorplan_cache_mode adicional para forçar planos genéricos ou personalizados. Para casos especiais, use com cuidado.
Você pode ganhar muito com as funções do lado do servidor que impedem viagens adicionais de ida e volta ao servidor de banco de dados do seu aplicativo. Faça com que o servidor execute o máximo possível de uma só vez e retorne apenas um resultado bem definido.
Evite aninhar funções complexas, especialmente funções de tabela ( RETURNING SETOF recordou TABLE (...)). Funções são caixas pretas que se apresentam como barreiras de otimização para o planejador de consultas. Eles são otimizados separadamente, não no contexto da consulta externa, o que simplifica o planejamento, mas pode resultar em planos menos que perfeitos. Além disso, o custo e o tamanho do resultado das funções não podem ser previstos com confiabilidade.
A exceção a esta regra são funções SQL simples ( LANGUAGE sql), que podem ser "incorporadas" - se algumas pré-condições forem atendidas . Leia mais sobre como o planejador de consultas funciona nesta apresentação por Neil Conway (material avançado).
No PostgreSQL, uma função sempre é executada automaticamente dentro de uma única transação . Tudo isso dá certo ou nada. Se ocorrer uma exceção, tudo será revertido. Mas há tratamento de erros ...
É também por isso que as funções não são exatamente "procedimentos armazenados" (mesmo que esse termo seja usado algumas vezes de maneira enganosa). Alguns comandos gostam VACUUM, CREATE INDEX CONCURRENTLYou CREATE DATABASEnão podem ser executados dentro de um bloco de transação, portanto, não são permitidos em funções. (Ainda não nos procedimentos SQL, a partir do Postgres 11. Isso pode ser adicionado posteriormente.)
Eu escrevi milhares de funções plpgsql ao longo dos anos.