Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

PostgreSQL 9.1 Released

Comments Filter:
  • Re:vs Oracle? (Score:5, Insightful)

    by h4rr4r (612664) on Monday September 12, 2011 @04:01PM (#37380178)

    It is easier, it is still wrong. It should be opt-in to prevent people from using it for new installations.

    It is not a subtle fucking difference. It is a huge big honking difference. Either you don't know the information which is null or you know it to be "".

  • Re:Hate to say it (Score:4, Insightful)

    by X0563511 (793323) on Monday September 12, 2011 @04:40PM (#37380618) Homepage Journal

    What's your point?

    Are you going to tell me word processors are boring, spreadsheets put you to sleep, and calculators suck the life out of the party?

  • Re:vs Oracle? (Score:5, Insightful)

    by cduffy (652) <charles+slashdot@dyfis.net> on Tuesday September 13, 2011 @01:49AM (#37383702)

    No foreign keys

    You mean just like MyISAM? It has it's [sic] uses.

    If we grant that a substantial set of use cases where a full-scale, non-embedded, out-of-process database is called for but relational integrity is unimportant exist (something I grant only for the sake of the ongoing argument), that still leaves people who try to use it in situations outside that set. I once took maintainership of an accounting system for car dealerships built on top of a "database" without relational integrity. Cases where bugs in the software resulted in orphaned records and numbers that didn't add up were legion.

    Saying you don't need relational integrity is right up there with saying you don't need bind variables because your hand-built escaping code is good enough. There might be cases where hand-built escaping is good enough, but encouraging J. Random Slashdot Reader to take that approach means it's going to be abused... and I assure you, the person who built that accounting system considered himself an expert.

    no guarantees of that data has been flushed to disk when a COMMIT comes back

    It uses a two-phase commit process. [mysql.com]

    Interesting documentation. Reading the links -- suffice to say that MySQL's multi-master clusters are vastly less safe than Oracle RAC. Depending on after-the-fact conflict resolution rather than having proper locking... really? (And with respect to NDB not supporting fsync() before reporting a commit complete -- yes, I can provide a link for that [mysql.com]. Being in a cluster isn't good enough -- sometimes you lose a rack, or a full DC).

    Yes, it's cheaper. Yes, it might be good enough for someone. But if someone needs RAC features enough to pay $50K in licensing fees for a tiny cluster, NDB just ain't gonna' cut it. And if I'm handling medical data (which I was last time I deployed RAC), I'm not going to risk massive liability by deciding that I can afford to get a COMMIT back before data is not just ACKed by multiple nodes but sitting on a platter.

    PostgreSQL 9.1's synchronous streaming replication is a sane middle ground -- it's not multi-master, but it actually preserves the same semantics and performance characteristics (durability semantics being the most critical of those -- but at the same time, needing to rewrite everywhere your code uses savepoints or autoincrement or relies on referential integrity exceptions because you're switching to a database backend that doesn't support them isn't any fun either) you'd have in a non-clustered environment. Having it available six years ago would have saved me one helluva lot of money.

    Provided whomever sets the cluster up knows what they are doing and doesn't half-ass it, it works just fine.

    Really? Compared to RAC, wherein moving to a cluster involves no loss of semantics, using NDB looks a whole lot like half-assing it already.

"Go to Heaven for the climate, Hell for the company." -- Mark Twain

Working...