Oh, I'm not saying that MySQL is a full-featured database, nor saying that I agree with the MySQL philosophy. I don't. That's why I'm trying to avoid MySQL. However PostgreSQL isn't any more accurate with FLOATs than MySQL is. The ANSI SQL standard for FLOAT is for an inaccurate number. It was never meant to be accurate, so even though MySQL has a much more liberal philosophy it's still behaving correctly when it does the math inaccurately. Which is just like I would expect PostgreSQL or DB2 or Oracle to do. If you need numeric accuracy and you pick FLOAT for your field, that *is* the developer's fault. You picked a screwdriver when you needed a chisel. Now, MySQL's design to 9-fill fields when you try to enter a too-large number is, in fact, stupid on MySQL's part. I consider that silent truncation. Heck, MySQL lets you create a date on February 31st, or prior to the year 1500, both of which are obviously nonsensical. -- Brandon Aiken CS/IT Systems Engineer -----Original Message----- From: pgsql-general-owner@xxxxxxxxxxxxxx [mailto:pgsql-general-owner@xxxxxxxxxxxxxx] On Behalf Of Ron Johnson Sent: Monday, August 28, 2006 6:27 PM To: pgsql-general@xxxxxxxxxxxxxx Subject: Re: [GENERAL] Precision of data types and functions -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brandon Aiken wrote: > To be fair, that's the fault of the previous designer, not MySQL. > You don't blame Stanley when your contractor uses 2" plain nails > when he needed 3" galvanized. The tool isn't to blame just > because someone used it incorrectly. Shows that you've been afflicted with the MySQL "app developer must do everything" disease. Just as a PK should not let you insert a duplicate record, a NUMERIC(12,2) should not let you insert a too-big number. Tool analogy: Pneumatic nailer says "maximum nail length 3 inches", but it *lets* you install *4* inch nails. So, you do what you can, it mis-fires and you nail your hand to the deck. Who's fault is it? Theirs, for making it easy to install 4 inch nails, or yours for doing it? That's where the analogy breaks down. DBMSs have *always* returned errors when the app tries to do something beyond the range of the DB's parameters. - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE823ES9HxQb37XmcRAi2bAKDXSW7ImqWSmpYKLGKFUxkdxtdz/QCgt2RM DiTn9wpUZoOJ8WIrFXxKmQ4= =U6SP -----END PGP SIGNATURE----- ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
