Neat trick, and some notes
This falls under "I knew I could do this but I didn't realize I could apply it this way!"
You can do
SELECT 1 from table1;
Which will return n rows, each row having 1 field whose value is 1. n is the number of rows in table1.
SELECT "string" from table1 works similarly.
However, I never considered using
SELECT "string" as "debug statement" to debug code.
For instance,
mysql> SELECT "SELECT foo from bar where baz>0" as "debug";;
+---------------------------------+
| debug |
+---------------------------------+
| SELECT foo from bar where baz>0 |
+---------------------------------+
1 row in set (0.00 sec)
Neat trick! This is why I follow the MySQL Users general list, because every so often a gem like this comes up. Plus, I can't resist helping folks out. And if I'm not accurate, someone else will step up.
Some more random thoughts, as I'm thinking about them and did not really want to make a separate post for them -- at the MySQL Users Conference, the rank on PlanetMySQL.com came up, from "the conference postings will increase my rank" to "so-and-so cheats and makes lots of little posts."
Now, I was just happy to make the list. Of course, now that I did post a lot at the conference, my rank went up from about #12 to about #7. As an experiment, I'm attempting to publish an average of one post a day for May and see what my ranking is at the end of May. So far, so good. And of course, as always, all of my posts will have content!
I think it would be neat to have a little line on planetmysql.com that shows where "1 post a day", "1 post a week" and "1 post a month" fall for the top posters.

Toby, Yep, that too.
Toby,
Yep, that too. Basically, if you're already capturing output, it's a way to capture debugging output without having to open another stream for writing to a file.
Sure, if you're running PHP code a "print" statement isn't that difficult. But yeah, a batch job, or other shell script....again, you could just use a "print" statement. But this gives another option, and set the level of the stack lower -- it has to GET to MySQL, and print the statement. Useful for folks who run PHP code saying "this query doesn't work!" and it ends up being that they can't connect.....
Usually I say:
1) print debug statements, and run those on the command line to see if the query itself works
2) try logging in manually to the machine, from the machine you're trying to use.
now they can
1) encapsulate the query in a SELECT "string" query and see if that works.
It will still fail if the user can't connect, but people are weird about printing debug statements.
Sheeri, disregard previous
Sheeri, disregard previous message, I realised it is of use during for instance a batch job piped to mysql client. Is that correct?
Hi, I read this post via
Hi,
I read this post via planetmysql but can you please explain why it's so clever, as I don't "get it". If you are logging queries, I don't see why you'd need to SELECT ""; and if you're not logging queries, how would you see the string unless you retrieved the result of the query that you just executed (the text of which you already have)?