-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brandon Aiken wrote: > 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. I don't think that any of us are criticizing MySQL for it treats floats, since we all (well, the dev team and most DBAs/developers) understand the pitfalls of real numbers. That has *nothing* to do, though, with the bug in question: mysql> create table test (a *numeric*(10,2)); Query OK, 0 rows affected (0.05 sec) mysql> insert into test values (123123123123123.2); Query OK, 1 row affected, 1 warning (0.00 sec) mysql> select * from test; +-------------+ | a | +-------------+ | 99999999.99 | +-------------+ 1 row in set (0.00 sec) > 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 > > 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 iD8DBQFE+RxpS9HxQb37XmcRApgwAJ9SoDyxTIDJqNKMVwD2nIsix2E4UwCfaIDf FVfyZ5VXf/0r6VXCC8QSDbM= =g3E8 -----END PGP SIGNATURE-----
