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

From Brandon Aiken
Subject Re: Precision of data types and functions
Date
Msg-id F8E84F0F56445B4CB39E019EF67DACBA21F65D@exchsrvr.winemantech.com
Whole thread Raw
In response to Re: Precision of data types and functions  (Ron Johnson <ron.l.johnson@cox.net>)
Responses Re: Precision of data types and functions
Re: Precision of data types and functions
List pgsql-general
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@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

-----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

pgsql-general by date:

Previous
From: Anastasios Hatzis
Date:
Subject: Duplicating rows in one table but with one column value different
Next
From: "Silvela, Jaime \(Exchange\)"
Date:
Subject: pg_statistic corruption and duplicated primary keys