On Wed, Jul 4, 2012 at 8:06 AM, Igor Tandetnik <itandet...@mvps.org> wrote: > Nico Williams <n...@cryptonector.com> wrote: >> SQLite3 also needs to know the identifiers of schema elements at >> statement prep time. It might be nice to have a variant of >> sqlite3_prepare_v2() that takes a varargs list of parameters which >> must be identifiers, and then have a syntax for referring to >> identifier parameters as opposed to value parameters. > > That doen't make much sense. The query plan for "select * from table1 where > col1=?" may be completely different from one for "select * from table2 where > col2=?". What exactly do you expect sqlite3_prepare_v2 to prepare, if table > and column could vary afterwards? Also, what are sqlite3_column_count, > sqlite3_column_decltype et al supposed to return?
Precisely, which is why any identifiers (table names, column names) have to be known at statement prep time. But using parametrized queries adds some safety, so it makes sense to me to have two types of parameters: those which must be bound at statement prep time, and those that can be bound later. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
