Pythian Group

Today’s contradiction:

MySQL has server variables named new and old.

The new variable can be set per-session and globally, and is dynamic. The old variable is not dynamic, and only global in scope. Both default to FALSE in MySQL 5.1.

According to the manual, the new variable:

was used in MySQL 4.0 to turn on some 4.1 behaviors, and is retained for backward compatibility.

That same page notes the following about the old variable:

when old is enabled, it changes the default scope of index hints to that used prior to MySQL 5.1.17. That is, index hints with no FOR clause apply only to how indexes are used for row retrieval and not to resolution of ORDER BY or GROUP BY clauses.

That’s right — the old variable changes some index hint behavior to before 5.1.17, and the new variable is provided for backwards compatibility of a 4.0 function.

Perhaps now that they have already used the vague terms, MySQL will stick to descriptive names, such as old_index_hints and new_behavior (or, even better, specifying what that new behavior is. If not in the variable itself, at least in the manual!)

Do you have_community_features? I do!

SHOW GLOBAL VARIABLES LIKE 'have_community_features';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| have_community_features | YES   |
+-------------------------+-------+
1 row in set (0.00 sec)

I am pretty sure this is one of those variables that MySQL has put in as an unused placeholder, but for now, it is not even documented as unused (as are table_lock_wait_timeout, http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html, and a Google search restricted to the site dev.mysql.com turns up only one match, which is not useful: http://www.google.com/search?q=site%3Adev.mysql.com+have_community_features

I wonder if Read the rest of this entry . . .