La comunidad de PostgreSQL retiró el 7 de septiembre el soporte de SQL/PGQ de la versión 19, la funcionalidad más ambiciosa del ciclo. SQL/PGQ, incorporado al estándar SQL en 2023, permite definir grafos de propiedades sobre tablas relacionales y consultarlos buscando patrones de nodos y aristas sin salir de SQL. La reversión, de miles de líneas de código, llega pocos días después de que el 27 de agosto se retirara también ALTER TABLE … MERGE/SPLIT PARTITION, que permitía fusionar y dividir particiones. Como consecuencia, la fecha de disponibilidad general de PostgreSQL 19 figura ahora como pendiente de fijar.
Ambas decisiones parten de una consulta que Robert Haas lanzó el 25 de agosto en la lista pgsql-hackers: si alguno de los seis grandes cambios que más parches habían necesitado tras la congelación de funcionalidades debía salir de la versión. En el caso de SQL/PGQ el motivo no fue un fallo concreto, sino problemas de diseño que no había tiempo de resolver en este ciclo. Tom Lane, uno de los desarrolladores más veteranos del proyecto, llegó a decir que apostaría una cena a que, si se publicaba en la 19, aparecerían errores tras el lanzamiento que no podrían corregirse hasta la 20. Con cinco años de soporte por delante para cada versión mayor, el proyecto prefirió no cargar con un diseño que no convencía.
El calendario lo refleja. La hoja de ruta oficial situaba el lanzamiento en septiembre de 2026, como es habitual en el proyecto, pero la página de seguimiento de la versión ya no da fecha ni para la versión candidata ni para la disponibilidad general. La cuarta beta está prevista para el 24 de septiembre, después de las publicadas el 4 de junio, el 16 de julio y el 13 de agosto. Parte del retraso se atribuye a que varias funcionalidades grandes entraron en las últimas semanas antes de la congelación y han necesitado correcciones posteriores.
La versión 19 conserva novedades relevantes para la operación diaria. Entre ellas destaca REPACK, que con la opción CONCURRENTLY reorganiza tablas permitiendo que otras transacciones sigan accediendo a ellas durante casi toda la operación, frente al bloqueo exclusivo de VACUUM FULL. También siguen las sentencias UPDATE/DELETE FOR PORTION OF para datos temporales, la activación en línea de las sumas de verificación de datos y la importación de estadísticas en postgres_fdw.
Para los equipos que planificaban actualizar a PostgreSQL 19 este otoño, lo prudente es probar la cuarta beta pero no comprometer ventanas de migración hasta que el proyecto publique fechas. Quien esperaba SQL/PGQ para modelar relaciones en grafo dentro de PostgreSQL tendrá que seguir recurriendo a extensiones como Apache AGE o a bases de datos de grafos dedicadas, porque su vuelta en la versión 20 tampoco está garantizada. La decisión, en todo caso, confirma la cultura del proyecto: una funcionalidad sale cuando está madura, no cuando lo marca el calendario.
Más en Dataprix: el ranking de plataformas y gestores de bases de datos de Dataprix
Fuente: PostgreSQL Wiki — PostgreSQL 19 Open Items
Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.