Comments on: An SQL Puzzle?

By: PHP-help » Log Buffer #182, a Carnival of the Vanities for DBAs

PHP-help » Log Buffer #182, a Carnival of the Vanities for DBAs — Fri, 12 Mar 2010 22:48:20 +0000

[...] now available. MySQL join-fu expert Jay Pipes has moved his blog to http://www.joinfu.com and starts with An SQL Puzzle and of course a follow up on the sql [...]

By: Øystein Grøvlen

Øystein Grøvlen — Tue, 09 Mar 2010 08:29:40 +0000

Looks like you are using MyISAM, not InnoDb.

By: saurabh deshpande

saurabh deshpande — Tue, 09 Mar 2010 08:26:34 +0000

well the result is

100,100
1,1

even with the autocommit on or off the result is same.

By: Roland Bouman

Roland Bouman — Tue, 09 Mar 2010 08:07:46 +0000

Completely agree about the CREATE TABLE…SELECT statement, I also agree about the outcome: one row: (100,100)

The fact that a statement is refused due to a constraint violation, does not mean the transaction should be rolled back. It should be up to the user to decide what to do with whatever happened before the violation. However, the statement that caused the violation should be refused wholly – not like MyISAM, where the rows up to the violation succeed, and the rest fails.

By: Øystein Grøvlen

Øystein Grøvlen — Tue, 09 Mar 2010 06:33:11 +0000

Since you are asking about what the behavior _should_ be, I would say that it should _not_ produce the error that you think are correct. In my opinion, if the table already exists, the select statement should not be executed. The existing MySQL behavior makes things pretty messy, especially when views are involved (see MySQL bugs 47132 and 49494).

Given that, the select statement should give one row: (100, 100).

By: Jay Pipes

Jay Pipes — Tue, 09 Mar 2010 02:49:39 +0000

LOL. Not yet!

By: Rob Wultsch

Rob Wultsch — Tue, 09 Mar 2010 00:51:38 +0000

Note
CREATE TABLE does not automatically commit the current active transaction if you use the TEMPORARY keyword.
http://dev.mysql.com/doc/refman/5.1/en/create-table.html

Implicit commit is evil and stupid. Ideally we the server should error and roll back, imho.

By: Darius Jahandarie

Darius Jahandarie — Mon, 08 Mar 2010 23:35:32 +0000

This can be prevented in drizzle with protos and atomic DDL statements, right?

By: Jay R.

Jay R. — Mon, 08 Mar 2010 22:40:57 +0000

Table modification statements automatically commit transactions, so the insert is committed before the temporary table is created.

Right?

By: Scott Noyes

Scott Noyes — Mon, 08 Mar 2010 21:47:13 +0000

A duplicate key error will roll back the statement. Is the puzzle why it doesn’t roll back the whole transaction, or why it even bothers to do the select given that the table already exists?