The most recent meeting of ISO/IEC JTC1 SC32 WG3 “Database Languages” took place from the 15th to the 19th of June 2026 in Stockholm. “WG3”, as we call it, works on standardizing the database languages SQL and GQL. In that meeting, a number of proposals that are of interest to SQL and PostgreSQL were accepted, which I want to report about here.
It’s been a while since SQL:2023 was published, and work on the SQL standard continues. Nowadays, everyone in the database field wants vectors, and SQL now has them, too.
I have been working recently on making various scanners and parsers in PostgreSQL thread-safe, and this article is a bit of a brain dump to record what I did, what the different steps were, because all of that was pretty difficult to piece together, and it might be worth recording somewhere what was found and learned.
Let’s stipulate that PostgreSQL has grown significantly in popularity over the last 20 years. I don’t know by how much, but certainly at least one order of magnitude, probably two or more.
Upgrades between PostgreSQL major versions are famously annoying. You can’t just install the server binaries and restart, because the format of the data directory is incompatible. Why is that? Why can’t we just keep the data format compatible?
I wrote recently about the performance of PostgreSQL when compiled with different compilers and optimization levels. Another dimension in that evaluation is link-time optimization (LTO).
When the PostgreSQL project makes a release, the primary artifact of that is the publication of a source code tarball. That represents the output of all the work that went into the creation of the PostgreSQL software up to the point of the release. The source tarball is then used downstream by packagers to make binary packages (or file system images or installation scripts or similar things), or…