[PLUG] Re: MySQL Statement?

[AthlonRob]

Randal L. Schwartz wrote:
> It's still not ACID compliant when data gets lost, even with InnoDB
> tables.  As long as you can store 1e20 into an int field, only to have
> it silently truncated to 65535, it's not going into any production use
> that *I* have for it.

Again, I'm not a MySQL guru, so I spoke with a few folks who are.
Everybody seems to be in agreement that if you're using InnoDB tables,
you're fully ACID compliant.  Now, I understand there is some difference
in interpretations for your above truncation case.  Some believe such
things have nothing to do with ACID, some believe the database should at
least warn you before the truncation, and some believe it should
outright refuse any query that tries to put a too-large number in to an
int field that isn't set up to hold said number.

Why you would be putting a huge number in to a field that isn't set up
to hold a huge number seems like an important question, as well.

But, fear not.  With MySQL 4.1 (the current recommended release) you can
configurably have warnings pop up for such queries.  In MySQL 5.0, you
can have warnings appear for such queries or have it outright refuse a
query that puts a too-large number in to an int field.  Yay for choice!

> AthlonRob> This ain't your father's MySQL.
> 
> Yeah, it's my confused uncle's MySQL. :)
> 
> PostgreSQL.  It just works.

MySQL.  It just works, too.  ;-)

Really, it's great to have choice out there... it keeps things
innovative.  Unfortunately there's a lot of MySQL-related FUD out there
mostly based around old issues that haven't existed for years.  Yes,
MySQL didn't support transactions and subqueries and such five years
ago.  But it does today... and it does a nice job of it today.

Rob