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.
> After the statement is prepared. TCL asks the statement: "What
> application variables do you have, and what are their names?"
> The statement tells TCL that it has a variable named "$columns".
> TCL says "I have a variable by that name", and so then TCL
> then calls sqlite3_bind_text() to stick the value of the $columns
> TCL variable into the SQLite variable. TCL then calls sqlite3_step()
> to run the statement.
...and now the contents of $columns (SQL variable) in the statement above,
has been replaced with the contents of $columns (TCL variable) - because the
variable names are "compatible". So - that was my assumption - we've got now:
{ SELECT column1, column2, column3 FROM some_table }
...which seems to be quite legal SQL statement.
It seems, there's something I'm still missing(?).
--
pozdrawiam / regards
Zbigniew Baniewski
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
