Cuidado com NULL em NOT IN: o erro silencioso que quebra suas consultas no PostgreSQL

O comportamento de NOT IN com NULL não é um bug do PostgreSQL, mas uma consequência direta da lógica de três valores (TRUE/FALSE/UNKNOWN) do SQL padrão, e o parser do Postgres aplica isso com precisão cirúrgica. Quando NOT IN é usado com subconsulta, o parser o transforma internamente em NOT (col = ANY(subquery)), e não em uma cadeia de <> ALL como na forma literal. Isso faz com que qualquer NULL no lado direito ou esquerdo torne a comparação UNKNOWN, descartando todas as linhas. A armadilha é silenciosa porque o resultado é sintaticamente válido, sem erros ou avisos.

O PostgreSQL 19 (beta desde 4/6/2026, versão final prevista para setembro) traz uma mudança estrutural no planejador: agora ele converte NOT IN em Hash Anti Join, mas só quando prova que NENHUM dos operandos pode ser NULL. Essa prova depende de três condições simultâneas: colunas marcadas como NOT NULL no esquema, rastreamento de nullabilidade em joins externos e uso de operadores B-tree/Hash (como =). Se falhar em qualquer uma, o plano volta ao SubPlan opaco, exatamente como nas versões anteriores. Ou seja: a otimização não resolve o problema lógico, só acelera os casos já seguros.

Antes do PostgreSQL 19, NOT IN com subconsulta nunca era convertido em anti-join, mesmo com colunas NOT NULL. O planejador simplesmente não verificava a nullabilidade. Agora, com a função sublink_testexpr_is_not_nullable (introduzida no commit 383eb21ebff, março/2026), o otimizador reconhece explicitamente quando NULL está ausente e ativa a conversão. É a primeira vez em 17 anos (desde o anti-join no PostgreSQL 8.4, 2009) que o planner trata NOT IN como um join de primeira classe, mas apenas sob garantia formal, não por inferência ou configuração.

Para engenheiros de dados, isso não é só sobre performance: é sobre previsibilidade. Um pipeline que usa NOT IN em uma view com coluna nullable pode funcionar por meses e quebrar do nada ao inserir um único NULL, sem log, sem alerta, só dados sumindo. Já o NOT EXISTS é determinístico: mantém linhas com NULL no lado esquerdo, pois pergunta 'existe correspondência?', não 'é diferente de todos?'. E com o PostgreSQL 19, quem já modelou colunas como NOT NULL ganha ganho de desempenho imediato, sem mudar código, enquanto quem usa NULLs continua exposto à mesma armadilha de 1996.