[wp-hackers] WPDB does not seem to support RENAME TABLE query

[Paul Menard]

On Sep 22, 2013, at 9:07 AM, "J.D. Grimes" <jdg at codesymphony.co> wrote:

> Are you sure the user has the correct permissions? A search online for "wpdb rename table" (https://www.google.com/search?q=wpdb+rename+table) brings up code in several plugins that seem to have done this. I don't see anything that should stop it. 
> 
> And what version of WordPress are you using? Those line number don't seem to match trunk or any of the recent versions (maybe trunk has changed since you posted this).


Yes, of course. The RENAME TABLE still executes. Just the pesky PHP Warning. The WordPress version I'm using 3.5.2 only because that is where the environment is setup. But same issue with 3.6 and 3.6.1. Yes, the line number is off because I had attempted to add some debug into the core code to see what was happening. Apologies. The correct line number for the PHP Warning is 1227 This is the code from WP 3.6 wp-db.php in the function query() It is in the while loop where the PHP Warning is generated. The warning is shown because $this->result is not set. There should at least be some check to ensure $this->result is set before passing into the while. 

	if ( preg_match( '/^\s*(create|alter|truncate|drop)\s/i', $query ) ) {
		$return_val = $this->result;
	} elseif ( preg_match( '/^\s*(insert|delete|update|replace)\s/i', $query ) ) {
		$this->rows_affected = mysql_affected_rows( $this->dbh );
		// Take note of the insert_id
		if ( preg_match( '/^\s*(insert|replace)\s/i', $query ) ) {
			$this->insert_id = mysql_insert_id($this->dbh);
		}
		// Return number of rows affected
		$return_val = $this->rows_affected;
	} else {
		$num_rows = 0;
		while ( $row = @mysql_fetch_object( $this->result ) ) {		<-- result not set when RENAME
			$this->last_result[$num_rows] = $row;
			$num_rows++;
		}

		// Log number of rows the query returned
		// and return number of rows selected
		$this->num_rows = $num_rows;
		$return_val     = $num_rows;
	}


The real issue however is at line 1215 (see first preg_match line above). The wpdb class has some crufty logic in that is attempts to figure out which queries would not return results. So in the current case CREATE, ALTER, TRUNCATE and DROP. I suggest adding 'rename' to that preg_match argument list since 'rename' is a valid SQL command. 

Without the 'RENAME' in the first if the logic falls through to the ELSE where the while loop generates the PHP warning. 


My solution as of this morning is to sub-cloass wpdb and replace the query function with my own version which includes the 'rename' as part of the preg_replace argument. This at least solves my issue.