PostgreSQL 19 graph queries fail the 'would you ship this?' test

PostgreSQL developers have pulled planned graph query support from version 19 over concerns that unresolved bugs could haunt the release. The feature, SQL Property Graph Queries (SQL/PGQ), became part of the SQL standard in 2023. It provides syntax for exploring relationships between nodes connected by edges. PostgreSQL's implementation was removed over unresolved issues, while version 19's release date remains unconfirmed. A fourth beta is scheduled for September 24. Longtime PostgreSQL contributor Tom Lane warned: "At this point I'd be willing to bet dinner that if we ship it in v19 there will be post-release bug discoveries that are unfixable until v20." Tom Kincaid, senior vice president of software engineering at PostgreSQL support and development company EDB, confirmed that PGQ will not be part of PostgreSQL 19. "The community wanted to work through a few more things before releasing it," he said. Database administrators still have something to look forward to, though: reclaiming disk space without shutting everyone out of a table for the duration. VACUUM FULL rewrites a table to reclaim space occupied by obsolete row versions and return it to the operating system. It holds an exclusive table lock throughout, blocking other reads and writes. Kincaid told The Register that the resulting interruption makes administrators reluctant to run it. "Middle-of-the-night calls have been a result of somebody doing a VACUUM FULL, and their customers can't get access to the data or someone wants to know why this is running," he said. The new REPACK command offers a CONCURRENTLY option that lets other transactions access the table during most of the operation. It still needs an exclusive lock when swapping the rewritten table and index files into place, but that lock is typically held only briefly. Ordinary REPACK holds the exclusive lock throughout. For admins hoping to avoid another midnight call, CONCURRENTLY is the important part. (R)