✅ Alternativa correta: D

A função atualizar_status_processo é definida com RETURNS INTEGER, ou seja, retorna um valor.

Em PostgreSQL, funções que retornam valores devem ser chamadas usando SELECT.

A) ❌ Errado no PostgreSQL nesse contexto.

CALL é usado para procedures (sem retorno), ou seja, quando a função retorna VOID.

Nossa função retorna um INTEGER, então SELECT é obrigatório.

B) ❌ EXECUTE em PostgreSQL é usado dentro de blocos dinâmicos PL/pgSQL, não diretamente no SQL.

Não é usado fora de blocos DO, FUNCTION ou PROCEDURE.

C) ❌ PERFORM é usado para ignorar o valor de retorno, o que não é o esperado aqui, pois queremos obter o total de processos encerrados.

Além disso, o uso de DO é mais indicado para scripts internos e não para chamadas simples de função.

E) ❌ Sintaxe incorreta e mistura de dialetos:

• EXEC é típico do SQL Server, não do PostgreSQL.
• As aspas também estão erradas.

Fonte: ChatGPT.

Funções que retornam valores (como esta, que retorna INTEGER) são chamadas com SELECT.

Alternativas:

• (A) CALL: só é usado com procedures, não com funções que retornam valores.
• (B) EXECUTE: usado dentro de comandos dinâmicos.
• (C) DO...PERFORM: possível, mas desnecessariamente complexo; PERFORM é usado para funções sem retorno ou cujo retorno será ignorado.
• (E) EXEC: sintaxe inválida em PostgreSQL.

Portanto, gabarito: D

By Futur DEV Estável.

No PostgreSQL, quando uma função retorna algum valor (número, texto, etc.), nós a chamamos exatamente como se estivéssemos consultando uma coluna: usando SELECT.

Então de cara nenhuma das outras alternativas se enquadram nesse tipo de questão.

Resposta D)

D executa a função e mostra o retorno. Atenção: C também executa validamente, mas descarta o resultado.

A função recebe o processo, altera seu status para 'Encerrado' e retorna a contagem de TODOS os processos encerrados da tabela, não só das linhas alteradas.

A) INCORRETA — CALL é para procedure

O código usa CREATE FUNCTION, não CREATE PROCEDURE. Uma função pode fazer UPDATE e continuar sendo função.

Correção:

SELECT atualizar_status_processo('12345-67.2023.5.01.0001');

B) INCORRETA NO CONTEXTO — EXECUTE exige preparação

O EXECUTE do SQL PostgreSQL roda uma instrução criada antes com PREPARE; não chama diretamente uma função. Essa preparação não foi informada.

Exemplo válido:

PREPARE p(VARCHAR) AS SELECT atualizar_status_processo($1);

EXECUTE p('12345-67.2023.5.01.0001');

C) TECNICAMENTE VÁLIDA — executa sem exibir o retorno

DO $$

BEGIN

PERFORM atualizar_status_processo('12345-67.2023.5.01.0001');

END;

$$ LANGUAGE plpgsql;

DO executa um bloco anônimo; PERFORM chama a função e descarta o INTEGER retornado. O UPDATE acontece normalmente. LANGUAGE após o bloco é válido.

PERFORM não exige função com retorno void. Pelo enunciado “corretamente chamada”, C também funciona. Se a intenção fosse exibir o retorno, seria D: há ambiguidade na redação.

D) CORRETA — chama e apresenta o valor

SELECT atualizar_status_processo('12345-67.2023.5.01.0001');

SELECT executa a função e mostra o INTEGER retornado. Isso não impede o UPDATE interno.

Exemplo: havia 4 processos encerrados e a função encerrou mais um; retorna 5.

E) INCORRETA — EXEC e aspas erradas

EXEC não é a chamada SQL nativa do PostgreSQL para essa função. A alternativa também abre aspas simples e fecha aspas duplas. Corrigir só as aspas não basta: use SELECT e o argumento entre parênteses, como em D.

MEMORIZE

Função + retorno visível: SELECT.

Função + retorno descartado em PL/pgSQL: PERFORM.

Procedure: CALL.

Instrução preparada com PREPARE: EXECUTE.

Fonte: documentação PostgreSQL 14 — CALL, DO, EXECUTE e PERFORM:

https://www.postgresql.org/docs/14/plpgsql-statements.html