witness the destruction of mysql

Θέλω να κάνω αυτό. Δεν συμπαθώ MySQL.

MSDE is free and orders of magnitude superior. I could say the same about Linix. Most choose it for emotional/religions reasons, not on sound business analysis.

I’ve now got a tool (almost complete) that slurps in a MySQL DB definition and spits out one for Postgres. I will post a link to it when I get creation of the enum tables working. (Instead of enums, Postgres uses constraints and extra tables.)

I had a few problems moving to FreeBSD 5 with MySQL, which ultimately caused by was shoddy code in InnoDB.

I just rewrote all our in-code SQL queries to be easily recognizable. They now all live in

FOO = <<-SQL
    SELECT blah
    FROM there
    WHERE x = 1
SQL

This will help us with moving away from MySQL.

Bob has also been exploring Postgres performance, but his results are preliminary

BAH! Sometimes I hate MySQL with a passion.

1) I "love" MySQL.
2) MySQL can burn in the "fiery" pits of Hell.

So, I test out my LOCATE commands to make sure I can actually get the correct positions:

SELECT
  LOCATE('"', String)+1 AS 'First Pos', 
  LOCATE('"', String, LOCATE('"', String)+1) AS 'Last Pos'FROM
  Table;

This would return 4 (I add one to the result to get the first character after the quote) and 8 for the first string we parse.

Now that I have my position finding statements debugged, I set about pulling a SUBSTRING with these numbers. Now SUBSTRING takes up to three variables. The String to be cut, the starting position, and the length of the cut.

So to use it, I would create a function like SUBSTRING (which happens to work great when tested), or in this case:

SUBSTRING(String, LOCATE('"', String)+1, LOCATE('"', String, 
LOCATE('"', String)+1)-(LOCATE('"', String)+1))

But of course this doesn’t work…

#@*%!^%

How frustrating.

How asinine is this?!? The best part is

“The auto-increment counter is stored only in main memory, not on disk.“

Let’s see how this lets us have fun.

1. Create a table with an auto-increment key
2. Insert two entries into said table
3. Delete entry with greatest key; note key value
4. Stop MySQL
5. Start MySQL
6. Insert a single entry into our favorite table

The newly inserted key value will be equal to the deleted key value. Wait, what? Another way to have fun with this is

1. Create a table with an auto-increment key
2. Insert a single entry into our favorite table; note key value
3. Delete entry (using where id =); table should be empty
4. Stop MySQL
5. Start MySQL
6. Insert a single entry into our favorite table

The newly inserted key value will be 1, regardless of the deleted key value. Why bother having auto_increment functionality if it always wants to reset itself?

Try this one!

create table A (i enum (‘a’) not null);
insert into A (i) values (‘b’)

Rather than failing the insert it inserts the empty-string into the enum column. What’s the point of having an enum?

I ran into this bug today. Yay!

autoincrement keys on InnoDB table types without binary logging turned on reset themselves upon a hard reboot, which happened to me on Friday by mistake. autoincrement keys are supposed to have a lifetime associated with the table. Crashing shouldn’t matter. This can have serious problems if the autoincrement value is used to assign message identifiers for delivery systems. Why can’t people just use PostgreSQL?