installer.php incorrectly allows '.' in a DB table prefix

well, i just realized it seems to be a mysql issue, actually (using mysql 4):

this works:
show tables like 'PREFIX_node_type';

this doesn't:
show tables like 'DBNAME.PREFIX_node_type';

so maybe we should throw a warning when installing/update if the db prefix is set up like that. (i've seen that combination used on sites sharing the user and other tables).

Seems a shame to just disallow dots, because they can be really useful across shared table installations across different databases. If there isn't a solution, of course this would be the next best thing. However, the only case I can think of where the dot fails is in this particular instance (the show tables like...)

I've posted a question at http://forums.mysql.com/read.php?101,147694,147694#msg-147694 to see if there might be another solution (to determine if a table exists). Although you mentioned there's a similar problem with db_lock_table? Does a manual query it creates with a dot also fail? Let's see, it would be: LOCK TABLES {DBNAME.PREFIX_tablename} WRITE;

Seems a shame to just disallow dots, because they can be really useful across shared table installations across different databases. If there isn't a solution, of course this would be the next best thing. However, the only case I can think of where the dot fails is in this particular instance (the show tables like...)

I've posted a question at http://forums.mysql.com/read.php?101,147694,147694#msg-147694 to see if there might be another solution (to determine if a table exists). Although you mentioned there's a similar problem with db_lock_table? Does a manual query it creates with a dot also fail? Let's see, it would be: LOCK TABLES DBNAME.PREFIX_tablename WRITE;

oops :)

so my understanding of this would be that new sites run through the installer would no longer be allowed to share tables across databases. however, an existing site, or a site overriding db_prefix in the settings.php file would still be able to override the behavior (although they would need to make the fixes manually in the appropriate .install files to work around any issues cropping up from this). is this correct?

if so, then i agree that perhaps this is the way to go for now (so long as we also add appropriate messages & documentation).

on the other hand, db_lock_table is probably broken on these sites too, since it depends on the malformed db_escape_table. it doesn't throw any errors on our sites using shared tables across multiple databases, although i'm not sure it would w/o further testing. however, from viewing the code, i suspect the tables aren't actually being locked now, so i need to look into that more.

however, testing in mysql, the query used by db_lock_table works fine with a dot prefix, so i believe we need to change that function to allow it, since it's used everywhere you set the cache or a variable (rather than just in the installer/updater with db_table_exists).