Welcome to the January 2008 Issue of Postgres OnLine Journal Magazine. In this issue we will have a special feature PostgreSQL 8.3 Cheatsheet
to commemorate the upcoming PostgreSQL 8.3 release and the new year. This cheat sheet will look similar in format to the Postgis Cheatsheet and will cover
standard PostgreSQL features as well as new features added to the 8.3 release.
In future issues we hope to provide similar cheatsheets that highlight certain PostgreSQL advanced and specialty features. Any thoughts on what topics people
would like to see in a cheatsheet are welcome.
Other interesting topics that will be covered in this issue to name a few
Part 2 of our PostgreSQL Anatomy Series. We shall delve into the details of the database structure.
CrossTab queries using TableFunc contrib
Using Open Office Base with PostgreSQL
Setting up PgAgent and using it for scheduled backups.
On another note - check out Andrew Dunstan's, minimum update Trigger. It will be nice to see this make it into the PostgreSQL 8.4 release. Granted we haven't had much of a need of this feature, but when you need it, it comes in very handy as demonstrated in Hubert Lubaczewski's related article Avoiding Empty Updates. We remember the first time we started working on MySQL a long long time ago - MySQL had this built in, but you couldn't turn it off. In certain situations such as when you have triggers this feature is often a misfeature. Granted I guess there are only a few cases where having this automatically on could be annoying especially when all the other Databases you work with don't do this and there is probably some overhead involved with checking which may not always outweigh the update/logging cost. Any rate as far as check-off lists goes for people who consider this a feature, it will be nice to cross this off the list as one reason why one would choose MySQL over PostgreSQL and better yet in PostgreSQL it is optional.
Even though I would never prefer MySQL over Postgres, I don't think features like these are withholding a lot of users from switching. Being able to scale postgres over more then 1 server is critical. Right now as a user we need to fall back to solutions as drbd or ill-featured, based on old versions, replication solutions.
For all it's weaknesses, MySQL does have working replication (at least I guess it's master/slave replication is usable).
I haven't used MySQL at all and I haven't yet used Slony as PostgreSQL's replication solution.
I am curious about the ways that Slony falls short as a Primary-Secondary replication solution when compared with MySQL's replication solution?