Uh-huh. That's because if Youtube loses a video of a cat with 3 views, who gives a flying fuck? Ask your bank or your credit card company what database they use to store their financial transactions. Probably won't be PostgreSQL, but it sure as hell won't be MySQL. And they're only using Oracle because $10M to them is chump change.

Indeed. About 0.0005 seconds of Googling brought me this as the first link:

http://www.postgresonline.com/journal/archives/24-Using-MS-Access-with-PostgreSQL.html

Though I think there are probably a grand total of 3 people on Earth who have used MS Access in any serious capacity and don't loathe it.

Eh? Not sure exactly what you mean, but the postgres documentation is built from SGML into several formats, such as a giant PDF or the web documentation. It's pretty darn good, and if you have quibbles with any of it, post to pgsql-docs and you'll have someone on the case pretty quickly.

Mod parent up. The Wal-Mart deal isn't actually that good, considering the offerings from Virgin Mobile, and Cricket. Not to mention Boost Mobile ($50 for unlimited everything, last I checked) and Metro PCS (similar unlimited pricing).

Personally, I keep my cell phone bill down around $10/month using prepaid minutes from T-Mobile. I've got an Android phone (G1, only $100 on eBay) and I can use sipdroid on it, combined with Google Voice and a free POTS->SIP accounts, for free minutes when I'm on wifi, which is most of the time.

Just stay the fuck away from AT&T and the other gorillas trying to lock you into overpriced 2-year plans and you'll do fine. Cell prices are finally coming down.

We need to learn to better respect the blue collar jobs. Without people doing those jobs our world doesn't work, yet people are taught from a young age that doing blue-collar work is something you should work to avoid.

Just throwing a relevant article recommendation, based on a book which is also a good read: Matthew Crawford's The Case for Working With Your Hands, based on the book Shop Class as Soulcraft. There is a puzzling bias against any blue-collar work in this country, regardless of how challenging or well-paying it may be. Ever look at the hourly rate your plumber charges? Or how much fun it might be to, say, work on cars or motorcycles for a living as compared to banging out TPS Reports?

Speak to your government about the enormous taxes they pile on top of that price.

I don't see why it' so terrible to pay gasoline taxes. We are dumping pollutants into the air with our cars, using the roads which our government funds, causing obnoxious noise and traffic jams...

I was just in Cuenca, Ecuador, where gas is $1.50 / gallon. The pollution from cars and buses in the city is unbearable: you can barely stand to walk around the city. Of course, hardly anyone walks anywhere, since a taxi anywhere within the city is a flat $2. The pollution is a real shame, since the city is situated in a picturesque valley tucked in the Andes mountains.

Yup. Look up SELECT ... FOR UPDATE for your database for the answer to your question, though again the real solution is just to use the appropriate sequence type provided by your RDBMS and let it do the work for you.

Not true, if you set things up properly. Look up STONITH -- it's quite easy to quickly turn a slave into the new master if your master dies (so long as you are sure the master is dead, and you can decide which slave to promote!).

Yup, that's the idea behind "asynchronous replication", and that's exactly how it's billed. If that's a deal-killer for you (for a large number of read-only queries it won't be.. think web applications where an eventually consistent state is perfectly fine) just wait until Postgres 9.1, when we should have more knobs for controlling master-slave replication. Then you should have the option to force the master to wait until a slave has received its WAL file update, and even fsync'ed it to disk, before your COMMIT returns, giving you the synchronous replication behavior you want.

The tradeoff with synchronous replication is increased latency on the master of course, since you're hanging around waiting for the slave to fsync (or just receive the data, depending on how you turn the knob). There have even been some proposals floating around for a "quorum commit" model whereby you would tell the master that you want your COMMIT; to go through when n out of m slaves have received the data.

Eh? When was multi-master replication ever promised in core? You're probably thinking about hot standby -- the Streaming Replication/Hot Standby code which is the "killer feature" of 9.0 was originally slated for 8.4, but didn't make it in time. I'm really surprised there aren't more comments about SR/HS, as it's an awesome feature which lets Postgres compete with the big boys like Oracle.

Imagine having your expensive database server be dedicated *only* to writes, and having all your read-only queries spread across one or more slave(s) which are also your backup servers. Pretty cool, huh?

Definitely not true. There's a lot of support to implement the MERGE command from the SQL standard. It's been proposed a few times, but it's more difficult than it sounds to implement. From here:

And work on MERGE support is itself blocked behind the fact that PostgreSQL doesn't have a good way to lock access to a key value that doesn't exist yet--what other databases call key range locking. See the notes for "Add SQL-standard MERGE/REPLACE/UPSERT command" at http://wiki.postgresql.org/wiki/Todo for more information.

Your gripe about CREATE ... IF NOT EXISTS might hold water, depending on what exactly you're complaining about (CREATE TABLE? Or for indexes/constraints?). There does seem to be some resistance to CINE, though from what I can tell it's mostly because people would rather have CREATE OR REPLACE, but COR is much harder to implement (what do you do when the object already exists, but is slightly different than the one you're trying to create)?

You're basically describing the SQL language itself (PostgreSQL does a good job of implementing most of the various SQL standards up to SQL-92 and even SQL-99). Of course, add-on procedural languages like Oracle's PL/SQL aren't going to be supported as-is anytime soon on PostgreSQL, or anywhere else. And of course, each database vendor has their own extensions to the SQL language itself, which other vendors aren't always keen to copy (think MySQL's INSERT ... ON DUPLICATE KEY UPDATE, or PostgreSQL's CLUSTER).

If you're designing a database application which you want to be easily portable across various SQL databases, just try to keep any non-standard-SQL use to a minimum and use of procedural languages simple and only when necessary. Books by Joe Celko stress this ideology, though my take is that it's just about impossible to really get the most out of your database unless you really make use of its extensions, which are there for a reason. For example, Celko discourages the use of auto-increment columns (serial type in Postgres, auto-increment primary key in MySQL), in favor of manually incrementing your sequence using MAX(pkey_column) or similar, which strikes me as absurd and non-scalable.