Comments on: Use parameters for field and table names in a MySQL Prepare statement to create truly dynamic SQL http://dev.af83.com/sql/use-parameters-for-field-and-table-names-in-a-mysql-prepare-statement/2007/05/30/ Shake your digital, we do WowWare Tue, 06 Jan 2009 04:29:05 +0000 http://wordpress.org/?v=2.3.3 By: Roland Bouman http://dev.af83.com/sql/use-parameters-for-field-and-table-names-in-a-mysql-prepare-statement/2007/05/30/#comment-21 Roland Bouman Thu, 21 Jun 2007 18:44:55 +0000 http://dev.af83.com/sql/use-parameters-for-field-and-table-names-in-a-mysql-prepare-statement/2007/05/30/#comment-21 "The mysql prepare statement sucks heavy time. You can not (!?!!!) use it to template field and table names." To my knowledge, no stored procedure language supports this for prepared statements. The entire idea of *preparing* a statement is that the database engine can parse a *statement*, optimize it, create a query plan for it and then afterwards reuse the handle to that statement. A statement template with place holders for structural elements (tables, columns etc) is syntactically not a statement, can thus not be parsed, and thus no plan can be created for it. A few comments on your code: #1: length() returns the number of *bytes* not the number of characters. There are multiple places in you code where this difference matters. #2: Inside your functions you are using user-defined variables (@variables) instead of proper local variables. This is unnecessary, and can have unwanted side effects. #3: You do not DEALLOCATE your prepared statements. This might not seem a big deal, but can be killing if you have a high load on your server. That is because the total number of prepared statements is limited. kind regards, Roland. “The mysql prepare statement sucks heavy time. You can not (!?!!!) use it to template field and table names.”

To my knowledge, no stored procedure language supports this for prepared statements. The entire idea of *preparing* a statement is that the database engine can parse a *statement*, optimize it, create a query plan for it and then afterwards reuse the handle to that statement. A statement template with place holders for structural elements (tables, columns etc) is syntactically not a statement, can thus not be parsed, and thus no plan can be created for it.

A few comments on your code:

#1: length() returns the number of *bytes* not the number of characters. There are multiple places in you code where this difference matters.

#2: Inside your functions you are using user-defined variables (@variables) instead of proper local variables. This is unnecessary, and can have unwanted side effects.

#3: You do not DEALLOCATE your prepared statements. This might not seem a big deal, but can be killing if you have a high load on your server. That is because the total number of prepared statements is limited.

kind regards,

Roland.

]]>