Zbigniew Baniewski schrieb:
On Thu, Jan 17, 2008 at 11:13:59PM -0500, D. Richard Hipp wrote:
The rules of TCL parsing are that text within {...} gets passed into
its command exactly as written with the outermost {...} removed. [..]
In other words, the $columns was *not* expanded by TCL. It got
passed down into SQLite.
Yes, I agree. But the following is not quite clear to me:
SQLite sees the $columns and thinks
you are dealing with an application variable. Just like a "?" or a
":abc" or "@xyz". Sqlite3_prepare() runs and treats the $columns
token as it would any other SQL variable.
So, TCL sees a variable "columns", whose contents ($columns) - is
"column1, column2, column3".
SQLite sees statement { SELECT $columns FROM some_table }, where $columns is
just "a token", which _can be_ an application variable, if TCL confirms
this.
Not really true.
If the part is wrapped in {} then for Tcl the $column is just an ordinary
string with no other meaning than foobar, and NO substitution takes place
before the string is passed to SQLite.
SQLite then interprets the string again, like some Tcl commands do
themselfes and defines the semantics for its argument as:
$name is an application variable if it appears in a place where an
application variable is valid.
This is then prepared as a statement and then values are bound by asking the
surrounding Tcl stackframe for the values of the Variables used.
Your usage fails, because the select list is no valid place to use
application variables, so SQLite does expand it there.
http://sqlite.org/c3ref/bind_blob.html has the details for the C side, only
literals can be replaced with application variables, and column names in the
select list are not really literals.
Michael
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
