I have no idea if and how this grant might affect Drupal's users to run it on shared hosting. I suspect that there will probably some hosters that cause problems - probably the same that cause problems with the LOCK TABLE permission on MySQL 4. This would be only another reason to recommend users to change hosters to such hosters that can do an upgrade from Mysql 3 to 4 _and_ read the upgrade docs.
I suggest that you or somebody else who is interested in the issue simply tries to run current Drupal HEAD on such a hosting account and reports back.
FWIW, The default value for MySQL's Create_tmp_table_priv is 'N'. Many shared hosting providers create a single administrative user with a GRANT ALL. While this is a bad idea, users on such a provider will not see any difference. Other hosting providers create administrative users and also site- specific users with minimal permissions. Odds are good that sites on these hosts will throw errors. We are in this category, and because roughly 1/3 of all sites we host use Drupal, we added the LOCK TABLES privilege to the list of site-user permissions. Frankly, I'm not too excited about adding yet another privilege to the list. So: +1 on using "big, bold letters" to highlight this issue in the docs +1 on donning flame-retardant attire and readying the fire extinguisher And because I'm a fan of the "too many settings!" dialog gridlock, I'll pose a question: can the advanced search features be optional? Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies