> "Postgres developers and users believe that quality view support is an
> important toolset for any database, and Postgres 9.3 includes several
> improvements to it's view support. Enhancements included in this
> release include the ability to create recursive views, to create
> automatically updateable views, and limited support for built in
> materialized views."
I still think that's soft-pedaling it far to much. If we don't toot our
own horn, who will? And "View improvements" is a pretty darned weak
promotional message compared to "Materialized View Declaration".
Regrading MatViews, let me explain why the Refresh locking isn't the
albatross which some people think it is. Currently, my clients, and
several OSS projects, have many applications which currently use tables
as materialized views. The common way to handle these is "BEGIN;
TRUNCATE matview; INSERT INTO matview SELECT ...; COMMIT;". This
produces the *exact same* locking pattern as the current REFRESH. While
more lock-sensitive patterns are possible, that doesn't mean people are,
in the mainstream, using them.
Thus 9.3 Matviews allow DB architects to do a task they have been doing,
with simpler, less code, and no loss of functionality. Further, with
simpler, more mainainable code, we can expect app developers who haven't
previously used matviews as a concept to try them. Further, we'll have
increases in functionality in the future (CONCURRENTLY in 9.4,
async/sync updates later, incremental updates, etc.), which never would
exist in an ad-hoc system, and which probably won't require any changes
in code built on 9.3 to take advantage of.
The purpose of advocacy, and release announcements, is to *promote*
PostgreSQL, not to advertise every bug we have and every limitation.
Nitpicky perfectionism may be useful when we're writing code, but it
seriously undermines the project if it appears in our advocacy
materials. What other open source DBMS even has the concept of
materialized views?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
