can't prefix cache* tables

This appears in both 6.x and 5.x, altough little bit differently. Submitting a patch against 6.x.

Background:
db_query("SELECT ... FROM {$table}") doesn't work because PHP itself does variable replacement using {$table}, see:
http://www.php.net/manual/en/language.types.string.php#language.types.st...

Looks good, committed! Needs to be ported back to Drupal 5.x.

5.x is using:
db_query("SELECT data, created, headers, expire FROM {%s} WHERE cid = '%s'", $table, $key) instead of 6.x direct "{$table}" which is also considered bad.

This patch is porting 6.x syntax to 5.x

For 5.x.

Just for the records. {%s}, $table is bad because the prefixing is done *before* the placeholders are replaced, so cache tables can only have the default prefix, and no table dependent prefixing. It might be good to sanitize the table name (which did not seem to be required in Drupal 6 before this patch).

The same patch (without the string concatenation style errors) was already sitting in the queue in http://drupal.org/node/126867 btw...

Doh, fixed coding style issues, thanks for noting! The 5.x patch still needs review from Niel.

Meba, although I fixed the coding style problem introduced earlier to Drupal 6 with your patch, the Drupal 5.x backport has that still. ".$table." should be ". $table ." (note the extra spaces around $table, one on each side.

Fixing code style.

Is it absolutely desired that db_query be ignorant of table prefix expansion when used with positional variables (%s, etc.)? If so, the quick modification to cache.inc:cache_set() to include the table in the query string is the best fix.

The code comment for database.inc:db_query() does not indicate this is the case (although it does not talk about handing off to db_prefix_tables for the substitution in its description text at all). If the case is that db_query should do prefix substitutions after variable substitutions, then http://drupal.org/node/152747 has a more robust table prefix expansion (necessary for when serialized data gets inserted in after variable expansion).

Honestly, I don't know why I spent time doing this the hard way, but if the simple way is canonical then arguably a note should be added to the function descriptions of db_query and db_prefix_tables to that effect.

The goal of using '%s' placeholder tokens is to ensure there are no SQL injection exploits using strings. Using %s (without quotes) in a query offers no security at all, and sets a bad example.

looks fine - applies cleanly - no errors/problems. However, the patch was made from /includes rather than the root directory. Patch attached differs only in this path for the patch.

@Steven- this is how HEAD does it and the cache table name will hopefully never be user input.

Tested and committed to 5.x.