I just committed a patch by Pavel Stěhule that adds the XMLTABLE functionality to PostgreSQL 10. XMLTABLE is a very useful feature dictated by the SQL/XML standard, that lets you turn your XML data into relational form, so that you can mix it with the rest of your relational data. This feature has many uses; keep reading for some details on it.(more…)
Over at pgsql-general, Bráulio Bhavamitra asks: I wonder if there is any plans to move postgresql entirely to a columnar store (or at least make it an option), maybe for version 10? This is a pretty interesting question. Completely replacing the current row-based store wouldn't be a good idea: it has served us extremely well and I'm pretty sure that replacing it entirely with a columnar store would be disastrous performance-wise for OLTP use cases.That doesn't mean columnar stores are a bad idea in general — because they aren't. They just have a more limited use case than “the whole database”. For analytical queries on append-mostly data, a columnar store is a much more appropriate representation than the regular row-based store, but not all databases are analytical.However,
Many years ago, Michelle Caise submitted a patch to generate code coverage reports for the PostgreSQL code base, based on the lcov utility. Although I cannot find any record of an actual patch in the mailing list archives, Peter Eisentraut committed it some time later, and applied further refinements later.Today I'm announcing a new PostgreSQL community service: code coverage reports generated automatically and updated daily using this infrastructure. I explain more details here.
If you've been following PostgreSQL development for the last few years, you've probably heard the term commitfest manager a few times. You probably already know what a commitfest is, but why is there a manager? Since I spent a good deal of time this past January managing one, I'll explain.At its heart, a PostgreSQL commitfest is just a collection of patches awaiting integration into the PostgreSQL code base. A commitfest's working principle is that each patch that has been sent to pgsql-hackers must be reviewed timely; once reviewed and revised enough times, the patch is candidate for permanent inclusion into PostgreSQL by a committer.As for the commitfest workflow: each new patch starts life in the commitfest in “needs review” state; it can be closed as “rejected” (breaking t