Y at-il un moyen de désactiver les règles de soumission lax dans sqlite?

Question

Il semble que SQLite, apparemment en tant que "fonction de compatibilité", analyse les identificateurs entre guillemets doubles comme des littéraux de chaîne si aucune colonne correspondante n'est trouvée. Je comprends que c'est le cas pour les personnes qui écrivent un SQL incorrect, et pour la rétrocompatibilité avec les projets hérités créés par de telles personnes, mais cela rend le débogage très difficile pour ceux qui écrivent correctement sql sur de nouveaux projets.

Par exemple,

SELECT * FROM "users" WHERE "usernme" = 'joe'; 

retourne une requête avec 0 lignes, puisque la chaîne 'usernme' ne correspond pas à la chaîne 'Joe'. Cela me laisse me gratter la tête en me demandant pourquoi je ne reçois pas la ligne de Joe même quand je sais qu'il y a un utilisateur de ce nom jusqu'à ce que je remonte minutieusement mon code et réalise que j'ai laissé un. Existe-t-il une option PRAGMA ou API «en mode strict» pour appliquer des règles de soumission et traiter toutes les chaînes entre guillemets comme des identifiants afin de m'informer immédiatement si une orthographe est mal orthographiée?

(Et s'il vous plaît, pas de réponses me disant de ne pas citer d'identifiants si je n'en ai pas besoin, car une telle réponse me dit essentiellement que pour obtenir un débogage correct, il faut d'abord écrire du mauvais code

Answer 1

Ceci est codé en dur dans l'analyseur SQLite et ne peut pas être modifié de l'extérieur.

Answer 2

J'ai aussi demandé dans le canal de SQLite et quelqu'un a eu la gentillesse de regarder à travers le code source et créer un patch, et même commencé un fil sur la liste de diffusion décrivant le patch:

http://www.mail-archive.com/sqlite-users@sqlite.org/msg73832.html

Ce n'est pas une réponse qui fonctionne pour les constructions officielles, mais ça pourrait être un jour. Pour l'instant, je vais juste le recompiler moi-même avec ce patch.