[sql] Use recover virtual table in sql::Recovery.

sql/recovery.cc

Index: sql/recovery.cc
diff --git a/sql/recovery.cc b/sql/recovery.cc
index e929ed93157c2efe545b53fd794b14246fa79088..9016f8a7eff988a939f26aee5bf26d28cd4d3d8f 100644
--- a/sql/recovery.cc
+++ b/sql/recovery.cc
@@ -72,6 +72,24 @@ bool Recovery::Init(const base::FilePath& db_path) {
   if (!recover_db_.OpenTemporary())
     return false;
 
+  // TODO(shess): Figure out a story for USE_SYSTEM_SQLITE.  The
+  // virtual table implementation relies on SQLite internals for some
+  // types and functions, which could be copied inline to make it
+  // standalone.  Or an alternate implementation could try to read
+  // through errors entirely at the SQLite level.
+  //
+  // For now, defer to the caller.  The setup will succeed, but the
+  // later CREATE VIRTUAL TABLE call will fail, at which point the
+  // caller can fire Unrecoverable().
+#if !defined(USE_SYSTEM_SQLITE)
+  int rc = recoverVtableInit(recover_db_.db_);

[erikwright (departed), 2013/07/26 17:56:57]

Any compelling reason for sqlite to not always initialize this module for every
database?

[Scott Hess - ex-Googler, 2013/07/26 18:04:08]

Having SQLite initialize it would make it available to web content.  In the
abstract that's not a problem, but for now it felt like a line I didn't want to
cross.

+  if (rc != SQLITE_OK) {
+    LOG(ERROR) << "Failed to initialize recover module: "
+               << recover_db_.GetErrorMessage();
+    return false;
+  }
+#endif
+
   // Turn on |SQLITE_RecoveryMode| for the handle, which allows
   // reading certain broken databases.
   if (!recover_db_.Execute("PRAGMA writable_schema=1"))