Update webdata files to take advantage of DLOG(FATAL) in

sql/statement.cc

Index: sql/statement.cc
diff --git a/sql/statement.cc b/sql/statement.cc
index fd73b0f588561f235d77d82529574ae7e16be05d..0074b72fd1c4158ca0e4340f36b5f1ca85087432 100644
--- a/sql/statement.cc
+++ b/sql/statement.cc
@@ -256,6 +256,10 @@ const char* Statement::GetSQLStatement() {
 }
 
 bool Statement::CheckOk(int err) const {
+  // TODO(shess,gbillock): This is only called by Bind*().
+  // Should there be a DLOG(FATAL) on it?

[Scott Hess - ex-Googler, 2011/12/15 23:02:57]

I maybe don't understand the comment.  I'd be fine with simply stating "Binding
to a position which doesn't exist is almost certainly wrong."

Unless the TODO is to decide whether to make it invalidate the statement?

[Greg Billock, 2011/12/16 17:26:58]

Yeah. This is basically a placeholder to move the conversation from the other
review to here.

The more I think about it, the more I'm convinced this should invalidate the
statement. An out-of-range error means, basically, that someone edited the
statement without editing the bind values, which is almost certainly disastrous.
We should think about better checks for this which can be applied cheaply. Does
sqlite already check to make sure all params are bound? Another idea would be to
bind typed params into the query with printf params. That would enlist the
compiler, and also provide a bit of type-safety in the doublecheck sense

[Scott Hess - ex-Googler, 2011/12/16 22:37:08]

Agreed.
Nope, they are implicitly bound to NULL, I think.
I'll work up my CL mentioned earlier.  I think our current API is pretty
reasonable WRT simplicity and type safety, and I'd rather not get too funky in
addressing making bindings reliable.  I think simply having the statement track
that parameters are bound in-order and completely would be sufficient.  The few
cases where skipping one can easily be addressed using a null.

+  if (err == SQLITE_RANGE)
+    DLOG(FATAL) << "Bind value out of range";
   return err == SQLITE_OK;
 }