Início / dba / Perguntas / 337709
Accepted
Roberto Iglesias
Asked: 2024-03-14 04:03:00 +0800 CST

Erro: tipo de parâmetro n (X) não corresponde ao da preparação do plano (Y)

  • 772

Estou encontrando um problema com uma função PL/pgSQL em que ela retorna diferentes tipos de dados com base em uma condição e resulta em um erro de incompatibilidade de tipo. Aqui está uma versão simplificada da função:

CREATE OR REPLACE FUNCTION public.test(lever int)
    RETURNS VARCHAR
    LANGUAGE plpgsql
AS $function$
DECLARE
    _new_record RECORD;
BEGIN
    -- Evaluating the random condition and returning different strings
    IF (lever = 0) THEN
        SELECT * FROM
        (VALUES(uuid_generate_anura()))x(id)
        INTO _new_record;
    ELSE
        SELECT * FROM
        (VALUES(10))x(id)
        INTO _new_record;
    END IF;
    RETURN pg_typeof(_new_record.id)::varchar;
END;
$function$;

Observe que esta é uma versão muito simplificada da minha função completa. Estou interessado em entender por que e como posso contornar isso.

Ao chamar esta função com lever = 0, ela retorna corretamente o texto uuid. No entanto, ao chamá-lo lever = 1para forçar a ELSEexecução da instrução, ocorre um erro:

postgres=# select test(0);
 test 
------
 uuid
(1 row)

postgres=# select test(1);
ERROR:  type of parameter 4 (integer) does not match that when preparing the plan (uuid)
CONTEXT:  PL/pgSQL function test(integer) line 15 at RETURN

Não importa o tipo de dados, o ELSEbloco sempre falhará.

postgresql

1 respostas

  1. Best Answer

    Não importa o tipo de dados, o ELSEbloco sempre falhará.

    Na verdade, a atribuição no ELSEbloco funciona bem. A mensagem de erro

    CONTEXT:  PL/pgSQL function test(integer) line 15 at RETURN

    refere-se a:

    RETURN pg_typeof(_new_record.id)::varchar;

    Uma variável do tipo (anônima)record pode conter qualquer tipo de linha , você pode até atribuir repetidamente tipos de linha incompatíveis à mesma variável dentro do mesmo bloco de código.
    Mas as funções PL/pgSQL (diferentemente das funções SQL) tratam todas as instruções SQL aninhadas como instruções preparadas. Mesmo recordos tipos devem ser iguais (ou correspondentes) em chamadas repetidas.

    Portanto, a primeira chamada da sua função sempre é bem-sucedida. Mas as chamadas subsequentes na mesma sessão deverão funcionar com a mesma declaração preparada.

    Se o problema for desencadeado apenas por um plano de consulta específico, podemos evitá-lo usando SQL dinâmico com EXECUTE, onde o plano nunca é salvo e reutilizado. Mas os testes indicam que a instrução preparada em si não permite a alteração do tipo de dados.

    Possível solução alternativa (conforme sugerido por Laurenz ): uma atribuição separada para cada filial. Cada instrução parece a mesma superficialmente, mas é preparada de forma diferente devido aos diferentes tipos de dados:

    CREATE OR REPLACE FUNCTION public.test(lever int, OUT result text)
  LANGUAGE plpgsql PARALLEL SAFE AS
$func$
DECLARE
   _new_record record;
BEGIN
   -- return different data types  (!) depending on input
   IF lever = 0 THEN
     SELECT random() AS id
     INTO _new_record;
   ELSE
     SELECT 10 AS id
     INTO _new_record;
   END IF;

   -- do stuff

   IF lever = 0 THEN  -- mirror cases at the top!
      result := pg_typeof(_new_record.id);  -- prepared differently!
   ELSE
      result := pg_typeof(_new_record.id);  -- prepared differently!
   END IF;
END
$func$;

    violino

    Relacionado:

    Pelo que vale, o exemplo que você mostra pode ser reduzido a esta simples função SQL (que não apresenta o mesmo problema):

    CREATE OR REPLACE FUNCTION public.test(lever int)
  RETURNS text
  LANGUAGE sql PARALLEL SAFE AS
$func$
-- Evaluate random condition and return different strings
SELECT CASE lever
          WHEN 0 THEN pg_typeof(uuid_generate_anura())
          ELSE pg_typeof(10)
       END;
$func$;

    Mas você já deu a entender que seu caso é mais complicado.

    • 2

relate perguntas