O nome (opcionalmente qualificado pelo esquema) da função a ser criada.

O modo do argumento: IN, OUT, INOUT, ou VARIADIC. Se omitido, o padrão é IN. Somente argumentos OUT podem seguir um argumento VARIADIC. Além disso, os argumentos OUT e INOUT não podem ser usados com a notação RETURNS TABLE. ^[126]

O nome do argumento. Algumas linguagens (incluindo SQL e PL/pgSQL) permitem o uso desse nome no corpo da função. Para outras linguagens, o nome do argumento de entrada é apenas documentação extra, no que diz respeito à própria função; mas pode-se usar nomes de argumentos de entrada ao chamar uma função para melhorar a legibilidade (veja Chamadas de função). Em todos os casos, o nome do argumento de saída é significativo, porque define o nome da coluna na linha de resultados. (Se for omitido o nome de um argumento de saída, o sistema escolherá um nome de coluna padrão.)

Os tipos de dados dos argumentos da função (opcionalmente qualificados pelo esquema), se houver. Os tipos de dados dos argumentos podem ser tipos base, compostos ou de domínio, ou podem fazer referência ao tipo de dados de uma coluna da tabela.

Dependendo da linguagem de implementação, também pode ser permitido especificar “pseudo-tipos”, como cstring. Pseudotipos indicam que o tipo de dados do argumento real está especificado de forma incompleta ou fora do conjunto de tipos de dados SQL comuns.

O tipo de dados de uma coluna é referenciado escrevendo nome_da_tabela.nome_da_coluna%TYPE. O uso desse recurso pode, às vezes, ajudar a tornar a função independente das alterações na definição da tabela.

Expressão a ser usada como valor padrão se o parâmetro não for especificado. A expressão deve ser conversível para o tipo de dados do argumento do parâmetro. Somente os parâmetros de entrada (incluindo INOUT) podem ter valor padrão. Todos os parâmetros de entrada que seguem um parâmetro com valor padrão também devem ter valor padrão.

O tipo de dados retornado (opcionalmente qualificado pelo esquema). O tipo de dados retornado pode ser um tipo base, composto ou de domínio, ou pode referenciar o tipo de dados de uma coluna da tabela. Dependendo da linguagem de implementação, também pode ser permitido especificar “pseudo-tipos”, como cstring. Se a função não deve retornar um valor, deve der especificado void como o tipo de dados retornado.

Quando existem parâmetros OUT ou INOUT, pode ser omitida a cláusula RETURNS. Se estiver presente, deve corresponder ao tipo de dados do resultado imposto pelos parâmetros de saída: RECORD se houver vários parâmetros de saída, ou o mesmo tipo de dados que o único parâmetro de saída.

O modificador SETOF indica que a função retorna um conjunto de itens, em vez de um único item.

O tipo de dados de uma coluna é referenciado escrevendo nome_da_tabela.nome_da_coluna%TYPE.

O nome da coluna de saída na sintaxe RETURNS TABLE. Esta é outra maneira de declarar um parâmetro OUT com nome, exceto que RETURNS TABLE também implica em RETURNS SETOF.

O tipo de dados de uma coluna de saída na sintaxe RETURNS TABLE.

O nome da linguagem na qual a função é implementada. Pode ser sql, c, internal, ou o nome de uma linguagem procedural definida pelo usuário, por exemplo, plpgsql. O padrão é sql se for especificado o corpo_sql. Colocar o nome entre apóstrofos é obsoleto, e requer letras maiúsculas e minúsculas correspondentes.

Lista as transformações aplicadas a uma chamada à função. As transformações convertem entre tipos de dados SQL e tipos de dados específicos da linguagem; veja CREATE TRANSFORM. As implementações das linguagens procedurais geralmente têm conhecimento codificado dos tipos de dados integrados, portanto, estes não precisam ser listados aqui. Se uma implementação de linguagem procedural não souber como lidar com um determinado tipo de dados, e não for fornecida nenhuma transformação, a linguagem adotará o comportamento padrão para converter tipos de dados, mas isto depende da implementação.

O atributo WINDOW indica que a função é uma função de janela, em vez de uma função simples. No momento, só é útil para funções escritas em C. O atributo WINDOW não pode ser alterado ao substituir a definição de função existente.

Estas cláusulas informam ao otimizador de consulta sobre o comportamento da função. Pode ser especificado no máximo uma dessas cláusulas. Se nenhum delas aparecer, é assumido VOLATILE por padrão.

A cláusula IMMUTABLE indica que a função não pode modificar o banco de dados, e sempre retorna o mesmo resultado quando recebe os mesmos valores de argumento; ou seja, não faz consultas ao banco de dados ou usa informações que não estão diretamente presentes em sua lista de argumentos. Se for especificada esta opção, qualquer chamada da função com todos os argumentos constantes pode ser imediatamente substituída pelo valor da função. ^[127]

A cláusula STABLE indica que a função não pode modificar o banco de dados, e que em uma varredura idêntica da tabela retorna consistentemente o mesmo resultado para os mesmos valores de argumento, mas que o resultado pode mudar conforme as instruções SQL. Esta cláusula é a escolha apropriada para funções cujos resultados dependem de consultas ao banco de dados, variáveis de parâmetro (como a zona horária corrente), etc. (Não é apropriada para gatilhos AFTER que desejam consultar linhas modificadas pelo comando corrente.) Note, também, que a família de funções current_timestamp se qualifica como estável, porque seus valores não mudam em uma transação.

A cláusula VOLATILE indica que o valor da função pode mudar mesmo em uma varredura idêntica da tabela, portanto, nenhuma otimização pode ser feita. Poucas funções de banco de dados são voláteis neste sentido; alguns exemplos são random(), currval(), e timeofday(). Mas note-se que qualquer função que tenha efeitos colaterais deve ser classificada como volátil, mesmo que seu resultado seja bastante previsível, para evitar que as chamadas sejam otimizadas; um exemplo é setval().

Para obter detalhes adicionais, veja a Categorias de volatilidade da função.

A cláusula LEAKPROOF indica que a função não tem efeitos colaterais. A função não revela nenhuma informação sobre seus argumentos, além de seu valor retornado. Por exemplo, uma função que emite uma mensagem de erro para alguns valores de argumento, mas não para outros, ou que inclui os valores dos argumentos em mensagem de erro, não é à prova de vazamentos. Esta cláusula afeta como o sistema executa consultas em visões criadas com a opção security_barrier, ou tabelas com segurança no nível de linha (RLS) ativada. O sistema aplicará as condições de políticas de segurança e de visões com barreira de segurança antes de quaisquer condições fornecidas pelo usuário da própria consulta que contenham funções não à prova de vazamentos, a fim de evitar a exposição inadvertida de dados. As funções e os operadores marcados como à prova de vazamentos são considerados confiáveis, podendo ser executados antes das condições das políticas de segurança e das visões com barreira de segurança. Além disso, as funções que não aceitam argumentos, ou que não recebem nenhum argumento de visão ou tabela, não precisam ser marcadas como à prova de vazamentos para serem executadas antes das condições de segurança. Veja CREATE VIEW e a Regras e privilégios. Esta cláusula só pode ser definida por superusuário.

A cláusula CALLED ON NULL INPUT (o padrão) indica que a função será chamada normalmente quando algum de seus argumentos for nulo. É então responsabilidade do autor da função verificar se há valores nulos, se necessário, e responder apropriadamente. ^[128]

A cláusula RETURNS NULL ON NULL INPUT ou STRICT indica que a função retorna nulo sempre que algum de seus argumentos for nulo. Se esta cláusula for especificada, a função não será executada quando houver argumentos nulos; em vez disso, o resultado nulo é assumido automaticamente.

A cláusula SECURITY INVOKER indica que a função deve ser executada com os privilégios do usuário que a chama. Este é o comportamento padrão. A cláusula SECURITY DEFINER especifica que a função deve ser executada com os privilégios do usuário que é o seu dono. Para obter informações sobre como escrever funções SECURITY DEFINER seguras, veja Escrita de funções SECURITY DEFINER seguras abaixo.

A palavra-chave EXTERNAL é permitida para manter a conformidade com o padrão SQL, mas é opcional, porque, ao contrário do padrão SQL, este recurso se aplica a todas as funções, e não apenas às externas.

PARALLEL UNSAFE indica que a função não pode ser executada em modo paralelo; a presença de tal função em uma instrução SQL força um plano de execução serial. Este é o padrão. PARALLEL RESTRICTED indica que a função pode ser executada em modo paralelo, mas apenas no processo líder do grupo paralelo. PARALLEL SAFE indica que a função pode ser executada com segurança em modo paralelo sem restrições, inclusive em processos trabalhadores paralelos.

As funções devem ser rotuladas com sem segurança para paralelismo (PARALLEL UNSAFE) se modificarem qualquer estado do banco de dados, alterarem o estado da transação (exceto pelo uso de uma subtransação para recuperação de erros), acessarem sequências (por exemplo, chamando currval) ou fizerem alterações persistentes nas configurações. As funções deverão ser rotulados com paralelismo restrito (PARALLEL RESTRICTED) se acessarem tabelas temporárias, estado de conexão do cliente, cursores, instruções preparadas, ou diversos estados locais do processo servidor que o sistema não pode sincronizar no modo paralelo (por exemplo, setseed não pode ser executada senão pelo líder do grupo, porque uma alteração feita por outro processo não seria refletida no líder). Em geral, se uma função é rotulada como segura quando é restrita ou insegura, ou se é rotulada como restrita quando na verdade é insegura, ela pode emitir erros ou produzir respostas erradas quando usada em uma consulta paralela. As funções da linguagem C poderiam, em teoria, exibir um comportamento totalmente indefinido se rotuladas incorretamente, porque não há como o sistema se proteger contra o código C arbitrário, mas, geralmente, o resultado não é pior do que para qualquer outra função. Em caso de dúvida, as funções devem ser rotuladas como UNSAFE, que é o padrão. ^[129]

Um número positivo que dá o custo de execução estimado para a função em unidades de cpu_operator_cost. Se a função retornar conjunto, este será o custo por linha retornada. Se não for especificado o custo, assume-se 1 unidade para a linguagem C e funções internas, e 100 unidades para funções em todas as outras linguagens. Valores maiores fazem com que o planejador tente evitar avaliar a função com mais frequência do que o necessário.

Um número positivo que fornece o número estimado de linhas que o planejador deve esperar que a função retorne. Só é permitido quando a função é declarada retornando conjunto. A suposição padrão é de 1.000 linhas.

O nome (opcionalmente qualificado pelo esquema) da função de suporte do planejador a ser usada para esta função. Veja Informações sobre otimização de funções para obter detalhes. É necessário ser um superusuário para usar esta opção.

A cláusula SET faz com que o parâmetro de configuração especificado seja definido com o valor especificado quando a função é chamada e, em seguida, restaurado para seu valor anterior quando a função é encerrada. A cláusula SET FROM CURRENT salva o valor corrente do parâmetro quando CREATE FUNCTION é executado como o valor a ser aplicado quando a função é chamada.

Se for anexada a cláusula SET a uma função, então os efeitos do comando SET LOCAL executado dentro da função para a mesma variável ficam restritos à função: o valor anterior do parâmetro de configuração ainda é restaurado na saída da função. No entanto, um comando SET comum (sem LOCAL) substitui a cláusula SET, tanto quanto faria para um comando SET LOCAL anterior: os efeitos desse comando persistirão após a saída da função, a menos que a transação corrente seja desfeita.

Veja SET e Configuração do servidor para obter mais informações sobre nomes e valores de parâmetros permitidos.

Uma constante cadeia de caracteres que define a função; o significado depende da linguagem. Pode ser um nome de função interna, o caminho para um arquivo objeto, um comando SQL, ou texto em uma linguagem procedural.

Muitas vezes é útil usar a delimitação por cifrão (veja Constantes do tipo cadeia de caracteres delimitadas por cifrão) para escrever a cadeia de caracteres de definição da função, em vez da sintaxe normal de apóstrofos. Sem delimitação por cifrão, quaisquer apóstrofos ou contrabarras na definição da função devem ser duplicados.

Esta forma da cláusula AS é usada para funções na linguagem C carregáveis dinamicamente, quando o nome da função no código-fonte da linguagem C não é o mesmo que o nome da função SQL. A cadeia de caracteres arquivo_objeto é o nome do arquivo de biblioteca compartilhada que contém a função C compilada, sendo interpretado como para o comando LOAD. A cadeia de caracteres símbolo_de_ligação é o símbolo de ligação da função, ou seja, o nome da função no código-fonte da linguagem C. Se o símbolo de ligação for omitido, é assumido como sendo igual ao nome da função SQL que está sendo definida. Os nomes C de todas as funções devem ser diferentes, então é necessário dar nomes C diferentes às funções C sobrecarregadas (por exemplo, usando os tipos de dados dos argumentos como parte dos nomes C).

Quando o comando CREATE FUNCTION é chamado repetidas vezes para o mesmo arquivo objeto, o arquivo objeto é carregado apenas uma vez por sessão. Para descarregar e recarregar o arquivo (talvez durante o desenvolvimento), deve ser iniciada uma nova sessão.

O corpo de uma função escrita em LANGUAGE SQL. Pode ser tanto uma única declaração

RETURN expressão

ou um bloco ^[130]

BEGIN ATOMIC
  instrução;
  instrução;
  ...
  instrução;
END

Esta forma é semelhante a escrever o texto do corpo da função como uma constante cadeia de caracteres (veja definição acima), mas existem algumas diferenças: esta forma funciona apenas para LANGUAGE SQL, enquanto a forma constante cadeia de caracteres funciona para todas as linguagens. Esta forma é analisada no tempo de definição da função, a forma constante cadeia de caracteres é analisada no tempo de execução; portanto, esta forma não pode dar suporte a argumentos com tipos de dados polimórficos, e outras construções que não podem ser resolvidas no momento de definição da função. Esta forma rastreia as dependências entre a função e os objetos usados no corpo da função, portanto, DROP ... CASCADE funcionará corretamente, enquanto a forma que usa literais cadeia de caracteres pode deixar funções pendentes. Finalmente, esta forma é mais compatível com o padrão SQL e outras implementações da linguagem SQL. ^[131]