PostgreSQL 19 entra no quarto beta cortando SQL/PGQ e tabelas temporais

O PostgreSQL Global Development Group publicou em 24 de setembro o quarto beta da versão 19 — e o número já conta parte da história: chegar ao beta 4 não é rotina em um projeto que costuma fechar o ciclo com dois ou três. O anúncio explica o motivo. Em vez de empurrar recursos meio prontos para a reta final, os mantenedores preferiram tirá-los da versão.

Cinco recursos revertidos

A lista de reversões é a parte mais relevante deste beta para quem já estava desenhando migração:

• SQL/PGQ, a sintaxe padronizada para consultas em grafo de propriedades sobre tabelas relacionais;
• ativação e desativação de checksums de dados com o banco no ar;
• UPDATE e DELETE temporais, via cláusula FOR PORTION OF;
• ALTER TABLE ... MERGE PARTITIONS e SPLIT PARTITIONS;
• as funções de leitura de DDL pg_get_role_ddl(), pg_get_tablespace_ddl() e pg_get_database_ddl().

Também caiu a mudança que forçava LC_COLLATE = 'C' no processo postmaster. Nenhum desses recursos foi abandonado: eles voltam para a fila de revisão e podem reaparecer em uma versão futura. A justificativa é a de sempre no projeto — prazo previsível e estabilidade valem mais que catálogo de novidades. Para quem mantém sistema em produção, essa é a boa notícia disfarçada de má notícia.

O que permanece na versão 19

Mesmo com os cortes, o PostgreSQL 19 segue substancial. O comando REPACK chega para reorganizar tabelas sem o ritual do VACUUM FULL, e o beta 4 traz correções nele para crash, índices inválidos, views materializadas, permissões e relato de erro. O WAIT FOR, novo comando de sincronização, ganhou ajustes em deadlock e em mensagens de erro por nível de isolamento.

A replicação lógica é a outra frente que evoluiu: detecção de conflitos, CREATE PUBLICATION ... EXCEPT e correções na sincronização inicial de tabelas e na compatibilidade entre versões. Some a isso o novo sistema de pontuação do autovacuum — incluindo o tratamento de tabelas TOAST —, a otimização com SIMD no COPY FROM e as melhorias no pg_plan_advice. Há também correções de desempenho em constraints de chave estrangeira e o conserto de um crash em detach concorrente de partição.

A janela de teste é curta

O release candidate é esperado para o início de outubro, com a versão final provavelmente no mesmo mês. Sobram poucas semanas úteis, portanto. O beta 4 exige procedimento de upgrade de versão maior — pg_upgrade ou o par pg_dump e pg_restore — e mudanças de API e de comportamento ainda são possíveis até o RC, então nada de apontar aplicação de produção para ele.

Se você mantém extensão, driver, ORM ou ferramenta de observabilidade, este é o momento de rodar a suíte contra o beta e abrir bug no formulário oficial. Reversões de última hora como as deste ciclo acontecem justamente porque alguém testou e reportou; a página de open items no wiki mostra o que continua em aberto.

O recado prático é curto. Se o seu roadmap contava com SQL/PGQ ou com FOR PORTION OF, replaneje agora. Se contava com REPACK e com replicação lógica mais esperta, siga em frente — só teste antes.