And so, it happened. After todays refresh of my Pg, I got:
$ SELECT version(); version ------------------------------------------------------------------------------------------------------------------------ PostgreSQL 9.2devel ON x86_64-unknown-linux-gnu, compiled BY gcc-4.5.real (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2, 64-bit (1 ROW)
Yes. We're in 9.2 development now. Looks like we got another really cool release coming soon.
Thanks a lot to all developers.
On 6th of March, Simon Riggs committed patch:
Efficient transaction-controlled synchronous replication. If a standby is broadcasting reply messages and we have named one or more standbys in synchronous_standby_names then allow users who set synchronous_replication to wait for commit, which then provides strict data integrity guarantees. Design avoids sending and receiving transaction state information so minimises bookkeeping overheads. We synchronize with the highest priority standby that is connected and ready to synchronize. Other standbys can be defined to takeover in case of standby failure. This version has very strict behaviour; more relaxed options may be added at a later date. Simon Riggs and Fujii Masao, with reviews by Yeb Havinga, Jaime Casanova, Heikki Linnakangas and Robert Haas, plus the assistance of many other design reviewers.
On 25th of February, Tom Lane committed patch:
Support data-modifying commands (INSERT/UPDATE/DELETE) IN WITH. This patch implements data-modifying WITH queries according TO the semantics that the updates ALL happen WITH the same command counter VALUE, AND IN an unspecified ORDER. Therefore one WITH clause can't see the effects of another, nor can the outer query see the effects other than through the RETURNING values. And attempts to do conflicting updates will have unpredictable results. We'll need TO document ALL that. This commit just fixes the code; documentation updates are waiting ON author. Marko Tiikkaja AND Hitoshi Harada
Well, saying that on particular date someone committed patch, wouldn't be really telling. In fact various bits and pieces of underlying logic have been committed for a long time, but now we finally have some functionality visible and available to end users.
This became the case thanks to these two commits, both committed on 20th of February, by Tom Lane.
Implement an API to let foreign-data wrappers actually be functional. This commit provides the core code and documentation needed. A contrib module test case will follow shortly. Shigeru Hanada, Jan Urbanski, Heikki Linnakangas
and second:
Add contrib/file_fdw foreign-data wrapper for reading files via COPY. This is both very useful in its own right, and an important test case for the core FDW support. This commit includes a small refactoring of copy.c to expose its option checking code as a separately callable function. The original patch submission duplicated hundreds of lines of that code, which seemed pretty unmaintainable. Shigeru Hanada, reviewed by Itagaki Takahiro and Tom Lane
On 18th of February, Itagaki Takahiro committed patch:
Add transaction-level advisory locks. They share the same locking namespace with the existing session-level advisory locks, but they are automatically released at the end of the current transaction and cannot be released explicitly via unlock functions. Marko Tiikkaja, reviewed by me.
Continue reading Waiting for 9.1 – Transaction level advisory locks
On 18th of February, Alvaro Herrera committed patch:
Convert Postgres arrays to Perl arrays on PL/perl input arguments More generally, arrays are turned in Perl array references, and row and composite types are turned into Perl hash references. This is done recursively, in a way that's natural to every Perl programmer. To avoid a backwards compatibility hit, the string representation of each structure is also available if the function requests it. Authors: Alexey Klyukin and Alex Hunsaker. Some code cleanups by me.
On 16th of February, Tom Lane committed patch:
Add FOREACH IN ARRAY looping to plpgsql. (I'm not entirely sure that we've finished bikeshedding the syntax details, but the functionality seems OK.) Pavel Stehule, reviewed by Stephen Frost and Tom Lane
On 12th of February, Robert Haas committed patch:
Teach ALTER TABLE .. SET DATA TYPE TO avoid SOME TABLE rewrites. WHEN the OLD TYPE IS BINARY coercible TO the NEW TYPE AND the USING clause does NOT CHANGE the COLUMN contents, we can avoid a FULL TABLE rewrite, though any indexes ON the affected COLUMNS will still need TO be rebuilt. This applies, FOR example, WHEN changing a VARCHAR COLUMN TO be OF TYPE text. The prior coding assumed that the SET OF operations that force a rewrite IS identical TO the SET OF operations that must be propagated TO TABLES making USE OF the affected TABLE's rowtype. This is no longer true: even though the tuples in those tables wouldn't need TO be modified, the DATA TYPE CHANGE invalidate indexes built USING those composite TYPE COLUMNS. Indexes ON the TABLE we're actually modifying can be invalidated too, of course, but the existing machinery is sufficient to handle that case. Along the way, add some debugging messages that make it possible to understand what operations ALTER TABLE is actually performing in these cases. Noah Misch and Robert Haas
Later on, on 15th, he committed second patch with few more cases where rewrite can be avoided.
Continue reading Waiting for 9.1 – Rewrite-less changing types of column
On 16th of February, , Robert Haas committed patch:
pg_ctl promote Fujii Masao, reviewed by Robert Haas, Stephen Frost, and Magnus Hagander.
On 8th of February, Peter Eisentraut committed patch:
Per-column collation support This adds collation support for columns and domains, a COLLATE clause to override it per expression, and B-tree index support. Peter Eisentraut reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch Branch ------ master
Continue reading Waiting for 9.1 – Per-column collation support