Por Canuto  

PostgreSQL 19 publicó su primera candidata a lanzamiento el 15 de octubre y tiene prevista su disponibilidad general para el 19 de noviembre. Peter Eisentraut atribuyó parte de la presión sobre el calendario a una revisión de código asistida por modelos de lenguaje que detectó más problemas de los que el equipo podía resolver a tiempo. Entre ocho y diez funciones se aplazaron, incluida SQL/PGQ.
***

  • PostgreSQL 19 publicó su primera candidata a lanzamiento el 15 de octubre; la disponibilidad general está prevista para el 19 de noviembre.
  • Los desarrolladores aplazaron entre ocho y diez funciones; Eisentraut vinculó parte de la presión con los defectos detectados durante la revisión asistida por modelos de lenguaje.
  • SQL/PGQ quedó fuera de esta versión por problemas sin resolver, mientras que algunas funciones aplazadas podrían llegar a PostgreSQL 20.

PostgreSQL 19 publicó su primera candidata a lanzamiento (RC 1) el 15 de octubre y tiene prevista su disponibilidad general para el 19 de noviembre. El calendario inicial ubicaba la salida hacia finales de septiembre o principios de octubre. En paralelo, los desarrolladores aplazaron entre ocho y diez funciones importantes y evaluaron una serie de defectos detectados durante la revisión del código.

Peter Eisentraut atribuyó parte de la presión sobre el calendario a la revisión asistida por modelos de lenguaje, que contribuyó a revelar problemas cuando quedaba poco margen para corregirlos antes del lanzamiento. Esto no significa que la IA haya originado necesariamente los defectos: la explicación apunta a que los hizo visibles durante una etapa tardía del ciclo de desarrollo. PostgreSQL anunció la RC 1 y la fecha prevista para la disponibilidad general en su comunicado sobre PostgreSQL 19 RC 1.

La revisión encontró más problemas de los que cabían en el calendario

La disponibilidad general de PostgreSQL 19 está prevista para el 19 de noviembre, después de que el calendario inicial apuntara a finales de septiembre o comienzos de octubre. El cambio coincide con la decisión de aplazar entre ocho y diez funciones significativas, algunas de las cuales podrían pasar a PostgreSQL 20, la versión siguiente.

Eisentraut explicó que algunas de las funciones retiradas tenían defectos de arquitectura que no resultaba realista resolver rápidamente durante la fase beta. En esos casos, no se trataba de corregir un detalle aislado, sino de abordar debilidades de diseño con suficiente cuidado para evitar incorporar riesgos a una versión cercana a su publicación.

La revisión con modelos de lenguaje también puso sobre la mesa una lista de defectos más acotados, vinculados con casos límite de distintas funciones. Eisentraut describió una cola de unos cuarenta informes y señaló que, aunque cada solución pudiera ocupar en promedio apenas tres líneas, revisar, entender, probar y cerrar cada reporte tiene un costo que se acumula cuando el tiempo disponible se agota.

La consecuencia fue que el equipo debió decidir qué podía corregir de manera segura y qué debía aplazar. Según Eisentraut, en ciclos anteriores algunos de esos casos quizá solo habrían salido a la luz después del lanzamiento y habrían generado correcciones durante los cinco años posteriores. La revisión asistida por LLM permitió encontrarlos con mayor rapidez, pero no eliminó el trabajo humano necesario para atenderlos.

La IA elevó el estándar después de que se escribieron las funciones

El momento en que mejoraron estas herramientas es parte central de la explicación de Eisentraut. Cuando se escribieron las principales actualizaciones previstas para PostgreSQL 19, la revisión de código asistida por LLM todavía no era tan útil como llegó a ser en los meses previos al lanzamiento, cuando los desarrolladores entendieron mejor cómo usarla y sus resultados se volvieron más efectivos.

Eisentraut describió ese cambio como un aumento del nivel efectivo de calidad exigido después de que las funciones ya se habían escrito y confirmado. La herramienta no necesariamente provocó los defectos originales: hizo que más problemas se detectaran en una etapa tardía, cuando corregirlos todos requería tiempo y capacidad de revisión que el calendario ya no ofrecía.

El responsable también diferenció este episodio del llamado vibe coding, una forma de desarrollo en la que se delega buena parte de la escritura del código a la IA. Según su explicación, esa técnica no estaba disponible cuando se escribieron la mayoría de las nuevas funciones de PostgreSQL 19, por lo que no atribuyó las reversiones a que el equipo hubiera generado el software de esa manera.

Su expectativa es que la situación pueda corregirse en ciclos futuros si las capacidades de revisión no siguen mejorando al ritmo que lo hicieron recientemente. La idea no es que una herramienta automática garantice por sí sola un lanzamiento sin fallos, sino que el proceso de desarrollo tendrá que adaptarse a la cantidad y al momento en que esas herramientas exponen problemas que antes podían quedar pendientes.

Funciones aplazadas y una versión que aún promete cambios

Una de las funciones que quedó fuera de PostgreSQL 19 es SQL Property Graph Queries, conocido como SQL/PGQ. Esta característica, incorporada al estándar SQL en 2023, ofrece una sintaxis para explorar relaciones entre nodos conectados por aristas. La implementación prevista para PostgreSQL se retiró debido a problemas que seguían sin resolverse; The Register informó sobre la salida de SQL/PGQ de esta versión.

El colaborador Tom Lane advirtió sobre el riesgo de incluirla sin más trabajo. Lane dijo que apostaría su cena a que, si SQL/PGQ salía en la versión 19, aparecerían después del lanzamiento errores que no podrían corregirse hasta PostgreSQL 20. La observación ilustra por qué los desarrolladores optaron por aplazarla en vez de asumir el costo de una implementación todavía problemática.

El aplazamiento no significa que PostgreSQL 19 vaya a quedar sin novedades. Eisentraut destacó REPACK CONCURRENTLY, una función que evita la operación VACUUM FULL, descrita como una operación que bloquea la tabla y se utiliza para recuperar espacio en disco. También sostuvo que el examen adicional debería contribuir a que el lanzamiento sea robusto.

La expectativa sobre PostgreSQL 20 también cambió con las reversiones. Meses atrás, algunos desarrolladores esperaban que esa versión se concentrara únicamente en corregir errores y no incorporara funciones nuevas. Ahora, Eisentraut considera probable que reciba parte de las características aplazadas desde PostgreSQL 19, aunque su llegada dependerá del trabajo pendiente.

Una base de datos con décadas de desarrollo

Postgres fue propuesto por primera vez por Michael Stonebraker en 1986. En 1994, Andrew Yu y Jolly Chen sustituyeron el lenguaje de consultas POSTQUEL por SQL y, al año siguiente, pusieron la base de datos a disposición del público para su uso y modificación bajo una licencia más permisiva, además de adoptar el nombre PostgreSQL.

Desde entonces, PostgreSQL se ha convertido en una de las bases de datos más populares entre desarrolladores profesionales. El crecimiento está relacionado, entre otros factores mencionados en la información del caso, con los servicios que los tres grandes hiperescaladores construyeron sobre ella y con la disponibilidad de sistemas distribuidos compatibles a nivel de protocolo.

Ese recorrido ayuda a entender por qué el equipo no trata el calendario como el único criterio para publicar una versión. En una base de datos utilizada en numerosos entornos, una función con problemas de arquitectura o una implementación con defectos difíciles de corregir puede trasladar consecuencias a usuarios y sistemas que dependen del software. Aplazar una característica permite mantenerla fuera mientras continúa el trabajo.

El caso de PostgreSQL 19 muestra, además, una tensión concreta para los proyectos de software: las herramientas de IA pueden acelerar la detección de problemas, pero cada hallazgo abre una tarea de análisis, corrección y verificación. Por ahora, los desarrolladores han preferido retrasar la disponibilidad general y reservar funciones para el ciclo siguiente antes que dar por resuelta una lista de defectos que, según Eisentraut, ya no cabía en el tiempo restante.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados