I have been invited to attend a Postgres security meeting at OmniTI in Maryland on September 8. The meeting will
include other local Postgres community members, government security experts, and contractors.

The goal of the meeting is for everyone to meet in person and to plan for necessary Postgres security additions and secure installation
guidelines. While this will be US-government specific, I expect all work products to be publicly released and available to benefit the
larger Postgres global community.

‘depesz’ already wrote a clear blog
entry explaining the effect of enabling standard_conforming_strings in Postgres 9.1. My blog entry explains why it will be changed in
Postgres 9.1.

To understand standard_conforming_strings, you have to know some Postgres history. Postgres is written in the
C language, and some C syntax was added to Postgres for convenience. For
example, Postgres supports the C syntax for not-equal, != , as well as the SQL-standard non-equal syntax, <>. This is a good addition
of C syntax because it does not affect SQL-standard-compliant behavior.

Continue Reading »

I am speaking at the New York PostgreSQL Meetup Group this Tuesday about the
new features in Postgres 9.0. (It will be similar to a webcast
I did a few months ago.)

I have a few interesting conferences coming up: SURGE (Baltimore),
OpenSQL Camp (Massachusetts),
PgWest 2010 (San Francisco), and perhaps PGDay Europe 2010
(Germany).

Continue Reading »

As a followup to my previous blog post, this humorous Slashdot
comment under the title “Reliability” warrants coverage:

Continue Reading »

Reliability Humor

Postgres implements Multiversion Concurrency Control (MVCC) using several
normally-invisible fields, notably xmin and xmax. The xmin column
records the transaction id that created the row, and xmax records
the transaction id that expired the row, either through an UPDATE or DELETE.

I often demonstrate MVCC by showing the xmin and xmax columns:

        SELECT xmin, xmax FROM mytable;
         xmin | xmax
        ------+------
          664 |    0
        (1 row)

Continue Reading »

Object-Relational Mappers are often a hot topic of discussion among database
geeks. At OSCON’s PGDay this year, Christophe Pettus presented
the clearest explanation I have ever heard of the complexities of ORMs and the basically unattainable expectations users have for them.
The basic problem is that it is easy to map simple ORM operations into SQL, but complex cases and mass changes require access to SQL for
performance. Christophe explained why ORMs increase programmer productivity, but also why ORMs will never be able to do everything SQL
can, so organizations should be prepared to add SQL to their ORM systems where appropriate.

A video recording was made of this talk and hopefully it will be posted soon.

While Steve Jobs tried to blame everyone but Apple for poor iPhone 4 reception, this
article calls this
long-term good news for the iPhone and smartphones in general because smartphone designers will increase their focus on call quality.
This mirrors the competing interests that are often involved in technological progress:

“Almost everything about technology, to me, is a response to a negative. Something isn’t working right. Something doesn’t look right.
Something doesn’t perform right,” Petroski told me. “And you try to remove that negative quality and that change is presumably an
improvement. But then you release the new and improved product and people find faults with it. Because nothing is perfect. You always have
competing constraints.”

Continue Reading »

I wrote an article about the Postgres development process for the Japan PostgreSQL Users Group (JPUG) and
they have now published it in English and
Japanese. It highlights many of the processes that make
Postgres open source development different, frustrating, and effective, with section titles like “No Single Authority”, “No Bug Tracking
System”, and “No Development Roadmap”.

Adding features to Postgres is often a frustrating experience for all involved. Some features are clear-cut, but many are subject to
interpretation and involve much email discussion. The email discussion is often draining, but this
comment from a Slashdot
thread about Linux desktop innovation is
illuminating. The comment is about human interface engineereers asking for tiny application changes to improve usability, and while the
application developer was originally “distracted trying to decide a fitting way to end the e-mail authors life”, he ultimately agreed that
the changes improved the user experience. I think Postgres developers often feel the same way.