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]
-----------------------------------------------------------------------------

Reply via email to