Telemetry reports slow SQL statements as-is, with comments, newlines, and extra whitespace. This makes the JSON harder to parse (bug 1592263, comment 3) and show in Redash, and also means we record, say, BEGIN and BEGIN DEFERRED TRANSACTION as separate statements.

SQLite has a sqlite3_normalized_sql interface that we can use. The docs also mention:

At a minimum, literal values will be replaced with suitable placeholders.

...suggesting we might not need to replace string literals with :private in SanitizeSQL.

It's a little unclear if the normalization would happen inside Telemetry or at the call sites... (if Telemetry normalizes it, will we be able to tell on the server where in the code the query came from?)

If it should happen in Telemetry it is unlikely that we'll have the bandwidth to do it ourselves this year : (

I wanted to see what kind of output sqlite3_normalized_sql returns, and if we could still match it up to the original query, but couldn't get Firefox to compile with it!

I added sqlite3_normalized_sql to third_party/sqlite3/src/sqlite.symbols, and tried to build, but got a linker error like:

Undefined symbols for architecture x86_64:
  "_sqlite3_normalized_sql", referenced from:
     -exported_symbol[s_list] command line option
ld: symbol(s) not found for architecture x86_64

I think that's all I had to do to add sqlite3_limit, so I'm confused about why this is failing. Mak, any ideas?

• Added support for the sqlite3_normalized_sql() interface, when compiling with SQLITE_ENABLE_NORMALIZE.

I guess you need to add SQLITE_ENABLE_NORMALIZE, I don't know if that option is not enabled by default because it has a cost (performance, safety, not sure), you can ask directly to the Sqlite users group or send an e-mail to Sqlite support to get information.