Re: Precision of data types and functions - Mailing list pgsql-general

-----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@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Ron Johnson
> Sent: Monday, August 28, 2006 6:27 PM
> To: pgsql-general@postgresql.org
> 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-----