And so, it happened. After todays refresh of my Pg, I got:
$ SELECT 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
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.
Continue reading Waiting for 9.1 – Synchronous replication
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
Marko Tiikkaja AND Hitoshi Harada
Continue reading Waiting for 9.1 – Writable CTE
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
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
Shigeru Hanada, reviewed by Itagaki Takahiro and Tom Lane
Continue reading Waiting for 9.1 – Foreign data wrapper
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
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.
Continue reading Waiting for 9.1 – Arrays in PL/Perl
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
Continue reading Waiting for 9.1 – FOREACH IN ARRAY
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:
Fujii Masao, reviewed by Robert Haas, Stephen Frost, and Magnus Hagander.
Continue reading Waiting for 9.1 – pg_ctl promote
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.
reviewed by Pavel Stehule, Itagaki Takahiro, Robert Haas, Noah Misch
Continue reading Waiting for 9.1 – Per-column collation support