PostgreSQL wasn't among the contenders.

Well thats a joke isn't it?

    Well thats a joke isn't it?

    Probably because postgresql also doesnt provide a lightweight version (like mysql), but mysql was included anyway.

      I can't imagine any flavor of Oracle being considered "lighter weight" than any version of PostgreSQL. Seriously.

      Might have been that it's not a commercial product, so they didn't know it existed. Happens to pgsql a lot.

        Man, that's another thing I like about PostgreSQL - it has just one flavor (and a lot of add-ons in contrib). All the others have a confusing array, and MySQL's even worse with its plethora of table types.

          There's an interesting analogue between PostgreSQL and MySQL though.

          In MySQL, certain tabel types have different behaviours, and some of those behaviours are down right unexpected in a database, like how trying to run a transaction on a mixed set of MyISAM and InnoDB tables can result in a partial rollback.

          The similar thing in PostgreSQL is the different index types. btree index types were, for quite some time, the only ones that were crash safe (transaction safe was never an issue really). This mean that if you chose hash, or rtree indexes, and the machine crashed unexpectantly, you could have an index that didn't match your table, and you'd have to use the reindex command to fix them. Worse still, you'd get no warning that they didn't match. You'd just get the wrong data. Note that this isn't on the same scale as the issues MySQL has with its different table types, since a crashing PostgreSQL server is actually pretty rare, and few people use any indexes other than Btree and the newer, crash safe GiST indexes, while lots of people use MyISAM tables in MySQL.

          Still, each database has its warts. The ones in PostgreSQL are hidden a little deeper, and I think they are fewer, but they're there. The difference is that none of the PostgreSQL folks are gonna blow sunshine up your skirt about it. Ask them a question about hash index types or something and one of the chief hackers will hop in and tell you they've got problems and should generally be avoided unless you know EXACTLY what you're doing.

          MySQL's marketing arm was once a bit too secretive about MySQL's warts. That seems to have changed in the last few years, with the ridiculous documentation claims that foreign keys and triggers are a bad thing, and relational integrity should be an application lever concern.

            Hehe. This kind of thing falls under the category of "No matter how beautiful a woman is, someone, somewhere, is sick and tired of her"

              Write a Reply...