> Let me explain better
>
> I'm moving an entirely column to another in the same table the variables
> are the columns names:
OK, that helps.
> $new_foo = "new_column";
>
> $old_foo = "old_column";
>
> When i use this statement everything is fine:
>
> $dbh->do(qq{UPDATE foos SET $new_foo = $old_foo});
>
> when i use i use placeholders like:
>
> $dbh->do(qq{UPDATE foos SET $new_foo = ?}, undef, $old_foo);
>
> i filled the "new_column" with zeros.
This is because placeholders cannot be used for column names,
only *values* (at least in most databases.)
The way to think about it is to think about the difference between
validating the structure of the SQL, vs. actually executing the SQL.
Everything that is needed to validate the SQL itself must be fixed
at prepare time, whereas things that are only needed to actually
execute the SQL can be postponed until execution time.
For example, consider this SQL:
update FOO set COL_A = COL_B where COL_A = ?;
Note that the validity of the statement, that is: that the table
exists; that the columns exist; that the syntax is valid; that
you have the permissions to execute it; etc.. can all be established
without reference to "?". Hence, you can have a "placeholder"
for the value that is supplied at execution time.
But this statement:
update FOO set ? = 10;
The database cannot prepare the query because it cannot determine if
the table foo has the missing column.
Admittedly, using "do", where prepare and execution are merged, this
distinction is less obvious. But this is core issue that you need to
grasp in order to understand why and where placeholders can be used.
Note that this is also in the DBI docs. See the section on placeholders.
Also, note that this is not a DBI constraint. This is a constraint
imposed by the underlying databases.
Mark
