SQLite supports a couple bind variants.
SELECT * FROM t WHERE c = ? AND d = ?
-- bind by number
SELECT * FROM t WHERE c = ?1 AND d = ?1
-- bind by number, but there's only one.
SELECT * FROM t WHERE c = :c AND d = :d
-- bind by name, can use $c or @c, too.
I think the ?NNN variant doesn't need any explicit support. I could
see us support binding like this:
db.execute("SELECT * FROM t WHERE c = :c AND d = :d", {"c": 10, "d": 20});
[Sorry if my syntax is wonky.] Obviously this isn't that interesting
to code this way, but it may be interesting if you think in terms of
JSON for data transfer. Even more interesting if you think of
embedding a JSON parser, because then we could just wire things up at
the C++ level (directly decode UTF-8 and feed it to the SQLite UTF-8
routines without forming real JS objects). This kind of idea would
also fit well with something like this:
db.execute("INSERT INTO t (c, d) VALUES (:c, :d)", [{"c": 10, "d":
20}, {"c": 15, "d": 5}, ...]);
where the code would prepare the statement once, then bind the inputs
in order. The main drawback is figuring out how to handle conflicts,
row-at-a-time makes that easy/obvious.
The TCL SQLite binding does this thing where it reaches out and
accesses the scope. So you can do things like:
set c "This is a value"
db eval {SELECT * FROM t WHERE c = $c}
I could imagine us having something like:
var c = "This is a value";
db.execute("INSERT INTO t (c) VALUES ($c)");
Just thinking out loud.
-scott
[I'm pretty sure I brought this up way back around launch, but I'm
reviewing SQLite 3.6.1 for Things To Watch For and ran across it
again.]
