DROP PROCEDURE — remove um procedimento
DROP PROCEDURE [ IF EXISTS ]nome[ ( [ [modo_do_argumento] [nome_do_argumento]tipo_de_dados_do_argumento[, ...] ] ) ] [, ...] [ CASCADE | RESTRICT ]
O comando DROP PROCEDURE remove a definição de um
ou mais procedimentos existentes.
É necessário ser o dono dos procedimentos para poder executar o
comando DROP PROCEDURE.
Os tipos de dados dos argumentos dos procedimentos devem ser
especificados, porque podem existir vários procedimentos diferentes
com o mesmo nome e listas de argumentos diferentes.
IF EXISTSNão lança erro se o procedimento não existir. É emitido um aviso neste caso.
nomeO nome (opcionalmente qualificado pelo esquema) do procedimento existente.
modo_do_argumento
O modo do argumento: IN, OUT,
INOUT, ou VARIADIC.
Se omitido, o padrão é IN (mas veja abaixo).
nome_do_argumento
O nome do argumento.
Note que o comando DROP PROCEDURE,
na verdade, não presta atenção aos nomes dos argumentos, porque
apenas os tipos de dados dos argumentos são necessários para
determinar a identidade do procedimento.
tipo_de_dados_do_argumentoOs tipos de dados dos argumentos do procedimento (opcionalmente qualificados pelo esquema), se houver. Veja abaixo os detalhes.
CASCADERemove automaticamente os objetos que dependem do procedimento, e, por sua vez, todos os objetos que dependem desses objetos (veja Acompanhamento de dependência).
RESTRICTRecusa remover o procedimento se algum objeto depender dele. Este é o comportamento padrão.
Havendo apenas um procedimento com este nome, a lista de argumentos pode ser omitida. Os parênteses também devem ser omitidos neste caso.
No PostgreSQL, é suficiente listar os
argumentos de entrada (incluindo INOUT), porque
duas rotinas com o mesmo nome não podem compartilhar a mesma lista
de argumentos de entrada.
Além disso, o comando DROP não verifica se foram
escritos os tipos de dados dos argumentos OUT
corretamente; portanto, quaisquer argumentos explicitamente marcados
como OUT são apenas ruído.
Mas escrevê-los é recomendável para manter a consistência com o
comando CREATE correspondente.
Para manter a compatibilidade com o padrão SQL,
também é permitido escrever todos os tipos de dados dos argumentos
(incluindo aqueles dos argumentos OUT) sem nenhum
marcador de modo_do_argumento.
Quando isto for feito, os tipos de dados do(s) argumento(s)
OUT do procedimento serão
verificados em relação ao comando.
Esta disposição cria uma ambiguidade, porque quando a lista de
argumentos não contém os marcadores de
modo_do_argumento,
não fica claro qual é a regra pretendida.
O comando DROP tentará a procura nos dois sentidos,
emitindo um erro se forem encontrados dois procedimentos diferentes.
Para evitar o risco dessa ambiguidade, é recomendável escrever os
marcadores IN explicitamente, em vez de deixá-los
serem o padrão, forçando assim ser usada a interpretação tradicional
do PostgreSQL.
As regras de procura explicadas acima também são usadas
por outros comandos que atuam em procedimentos existentes, como
ALTER PROCEDURE e
COMMENT ON PROCEDURE.
Havendo apenas um procedimento do_db_maintenance,
este comando é suficiente para removê-lo:
DROP PROCEDURE do_db_maintenance;
Dada esta definição de procedimento
CREATE PROCEDURE do_db_maintenance(IN target_schema text, OUT results text) ...
qualquer um desses comandos funcionaria para removê-lo:
DROP PROCEDURE do_db_maintenance(IN target_schema text, OUT results text); DROP PROCEDURE do_db_maintenance(IN text, OUT text); DROP PROCEDURE do_db_maintenance(IN text); DROP PROCEDURE do_db_maintenance(text); DROP PROCEDURE do_db_maintenance(text, text); -- potencialmente ambíguo
Entretanto, o último exemplo seria ambíguo se também existisse, digamos,
CREATE PROCEDURE do_db_maintenance(IN target_schema text, IN options text) ...
Este comando está em conformidade com o padrão SQL, com as seguintes extensões do PostgreSQL:
O padrão permite a remoção de apenas um procedimento por comando.
A cláusula IF EXISTS
A capacidade de especificar modos e nomes dos argumentos, e as regras de procura diferem quando os modos são fornecidos.