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