PostgreSQL 19 sortira sans une dizaine de ses nouveautés

Un classement demandé à Claude

Le 25 août, Robert Haas poste un message intitulé « scary patch contest » sur la liste des développeurs de PostgreSQL, la base de données libre née à Berkeley dans les années 1980. Haas fait partie des committers, ceux qui ont le droit d'intégrer du code au projet. Il a demandé à Claude de désigner les nouveautés de la version 19 qui font le plus peur, d'après le nombre et la nature des bugs corrigés depuis le gel des fonctionnalités. Il publie le classement, en précisant avoir coupé quelques remarques particulièrement cinglantes de la machine.

Six candidats. Le plus corrigé, REPACK, une commande de maintenance, a reçu 28 correctifs. Les sommes de contrôle activables à chaud, environ 25. Les requêtes de graphes, 17. Haas ne tranche pas : il demande si certaines doivent sortir de la version avant sa publication.

Le même jour, Tom Lane, autre committer, se dit prêt à parier un dîner : si les requêtes de graphes sortent dans la 19, on y trouvera des bugs impossibles à corriger avant la 20. Son argument ne doit rien à l'IA. Des correctifs encore en discussion exigent de toucher au catalogue interne de la base.

Une dizaine de nouveautés renvoyées

Le 7 septembre, les requêtes de graphes sont retirées. Ajoutées à la norme SQL en 2023, elles servent à parcourir des relations, comme un réseau d'amis ou une chaîne de fournisseurs. Le retrait annule 47 modifications : la fonctionnalité d'origine et 46 retouches arrivées depuis. C'est Peter Eisentraut qui le signe, l'un de ses deux auteurs.

Elle n'est pas seule. Dans un billet publié le 9 octobre, Eisentraut compte environ 8 à 10 fonctionnalités significatives retirées de la 19, « selon la façon de compter », certaines très tard dans la bêta. D'habitude, on en attend peut-être une par cycle. Dans l'historique public du projet, on retrouve notamment GROUP BY ALL, un raccourci de regroupement (retiré le 17 juillet), la fusion et la découpe de partitions (27 août), les mises à jour sur une portion de période (15 septembre).

Le calendrier a glissé aussi. Le 28 septembre, l'équipe de publication annonçait la version finale pour le 29 octobre. Le 10 octobre, elle la repousse au 19 novembre. C'est une date prévue, valable sauf si un problème est découvert d'ici là, précise l'annonce de la première version candidate, sortie le 15 octobre.

Les versions 16, 17 et 18 étaient toutes sorties en septembre. Depuis 2016, aucune version majeure n'était sortie après le 18 octobre.

La barre a monté après la copie rendue

Pourquoi tant de retraits ? Eisentraut avance plusieurs pistes, probablement combinées, et différemment pour chaque fonctionnalité. Il précise que ce ne sont que ses opinions. La première est sans détour : peut-être que le code n'était tout simplement pas assez bon.

Celle que la presse a retenue est une autre. Les gros défauts d'architecture mis à part, il décrit une longue traîne de problèmes plutôt bénins, des cas limites qu'on aurait autrefois corrigés petit à petit pendant cinq ans. Avec la relecture assistée par des LLM, ils remontent d'un coup. On peut alors se retrouver, écrit-il, devant une liste d'une quarantaine de rapports. Même si chacun ne demande que trois lignes de correction, chacun a un coût fixe, et le temps vient à manquer.

D'où sa formule : la barre de qualité a été relevée après l'écriture du code. C'est un examen dont on change le barème une fois la copie rendue. La plupart des fonctionnalités retirées, selon lui, ont été écrites il y a longtemps, quand la relecture par LLM était loin d'être aussi utile.

Relu avec l'IA, pas écrit par elle

La distinction compte. Eisentraut écarte le « vibe coding », ce code produit à la chaîne en dialoguant avec une IA, mais avec prudence : pour l'essentiel, et autant qu'il puisse en juger, la situation n'en vient pas, puisque ce code a été écrit bien avant que ce soit possible. Daniel Gustafsson, autre committer, le disait déjà fin août : la plupart des grosses nouveautés de la 19 ont été écrites, relues et testées avant que les outils d'IA soient disponibles, ou même vaguement aussi bons qu'aujourd'hui.

Dans le fil de Haas, les autres parlent d'impressions, pas de mesures. Nathan Bossart a le sentiment qu'on trouve davantage avec les LLM. Richard Guo s'attendait à ce que l'aide de l'IA rende les nouveautés plus stables au moment du gel, et constate que ça ne semble pas être le cas. Amit Kapila y voit un gain de stabilité à long terme, au prix de plus de correctifs à court terme.

Eisentraut donne un exemple de ce qu'aucun humain ne teste à la main : une requête sur un domaine défini sur un type composite, dans une partition détachée puis rattachée avec un autre ordre de colonnes, appelée depuis un trigger. Personne ne peut énumérer ces cas, écrit-il. Un fuzzing assisté par LLM, qui bombarde le code d'entrées générées, peut y trouver des problèmes très vite.

L'outil n'est pas un oracle pour autant. Paul Jungwirth, auteur des mises à jour par période, raconte avoir demandé à Claude un plan de tests croisés. Claude a écrit des tests, sans trouver un seul nouveau bug. D'autres en ont trouvé deux depuis.

Le report a un autre motif

Reste le glissement de calendrier, que The Register attribue aux relecteurs IA. Le message officiel du 10 octobre donne une autre raison : le volume de correctifs ajoutés aux versions déjà en service. L'équipe veut les intégrer à une seconde version candidate, le 12 novembre, jour de la mise à jour trimestrielle, avant la sortie finale. Les retraits, eux, devaient justement servir à tenir les délais : plutôt que retarder pour corriger, la communauté a préféré s'y tenir, écrit Eisentraut.

Un fil relie pourtant les deux. D'avril à août, beaucoup de développeurs expérimentés étaient occupés à corriger des failles de sécurité, raconte-t-il, ce qui a réduit la relecture habituelle de la bêta. Il appelle cette période la « Vulnpocalypse ». En juin, sur la liste de sécurité oss-security, le mot désignait la vague de failles trouvées par des IA qu'on voyait arriver.

La page sécurité de PostgreSQL recense 44 failles datées de 2026, dont 28 corrigées en août, contre 7 pour chacune des trois années précédentes. Elle ne dit pas qui les a trouvées.

Ce que la 19 garde

La version conserve REPACK CONCURRENTLY, qui réorganise une table sans la bloquer, et des conseils pour orienter le plan d'exécution des requêtes. Elle sera très robuste, promet Eisentraut, après tout ce surcroît d'examen. La 20, dont il disait il y a quelques mois qu'elle pourrait n'avoir aucune nouveauté, hérite déjà de fonctionnalités prêtes à 80 %.

Chez Linux, un correctif sur dix se déclare désormais assisté par l'IA, surtout chez des habitués qui réparent. Chez PostgreSQL, la machine trouve chez les habitués ce qu'ils n'avaient pas vu, et selon Eisentraut, le goulot d'étranglement devient le temps des humains qui doivent réparer.

Eisentraut pense que la situation devrait se régler d'elle-même aux prochains cycles. À une condition, qu'il pose lui-même : que la relecture par LLM cesse de progresser au rythme actuel.