Compilation bornée et preuves de schéma
La compilation refuse toute entrée dépassant 4,194,304 unités UTF-16, 131,072 jetons lexicaux hors End, 8,192 niveaux de groupement ou 65,536 nœuds AST. Le parcours itératif et le rendu borné préservent l’ordre des paramètres et le refus en cas de preuve insuffisante pour les six fournisseurs. Ils ne garantissent pas une profondeur SQL arbitraire.
Les budgets sont de 8,000,000 unités de travail par étape, 32,000,000 par compilation, 30 secondes par étape, 90 secondes par compilation et 536,870,912 octets d’allocations managées cumulées par étape. Ce sont des limites de compilation, pas des délais de requête DB ni des limites de mémoire du processus. Des diagnostics de ressources typés signalent les refus.
Un instantané de schéma immuable, facultatif, résout les noms de tables et colonnes ainsi que les familles de types prouvables, y compris les projections ordonnées CTE/dérivées. Son condensat est lié à l’empreinte du plan. Ce n’est pas un vérificateur complet des types DB. Le DML avec preuve de schéma exige une vérification de fraîcheur réelle ; une preuve absente ou modifiée entraîne un refus. Aucun instantané n’est capturé par défaut. AddHsSqlAgentNativeDmlSchemaFreshness() active le support natif facultatif.
hs-sql-agent ne traite jamais le SQL généré comme une commande fiable. La frontière d’exécution repose sur l’analyse, la validation, la vérification des capacités, les politiques d’accès et la compilation propre au moteur de base de données.
Chemin d’une requête
À haut niveau, une requête suit les étapes suivantes :
- Authentifier la clé MCP et appliquer son périmètre de base de données, de tables, d’outils et d’exécution.
- Analyser le SQL pris en charge pour produire une définition structurée / AST.
- Valider l’instruction et la sémantique source prise en charge.
- Vérifier les capacités de la cible nécessaires pour préserver cette sémantique.
- Compiler et produire le SQL adapté au moteur configuré.
- Exécuter dans les limites d’exécution configurées.
Le compilateur SQL contient des étapes explicites de validation de la source et de vérification des capacités de la cible. Une syntaxe non prise en charge, ou une capacité qui ne peut pas être démontrée, est refusée au lieu d’être remplacée silencieusement par une construction simplement similaire.
Pourquoi refuser par défaut ?
Le SQL multi-base comporte de nombreuses constructions qui semblent équivalentes mais diffèrent par leur comportement avec NULL, leurs règles de type, la sémantique des opérateurs, la pagination, les identifiants, les fonctions ou encore le comportement DML.
Sur une surface d’exécution destinée à l’IA, une réécriture « au mieux » est dangereuse : une instruction peut rester syntaxiquement valide tout en changeant de sens. hs-sql-agent préfère donc un refus visible à une dégradation implicite de la sémantique. C’est le principe de fonctionnement fail-closed appliqué au compilateur.
Sortie propre au moteur
L’interface MCP publique est commune, mais le SQL final dépend du moteur ciblé. Les moteurs actuellement pris en charge sont :
- PostgreSQL
- MySQL
- SQL Server
- Oracle
- SQLite
- Firebird
La prise en charge est volontairement bornée. Le fait qu’un moteur soit pris en charge ne signifie pas que toutes les syntaxes proposées par cette base sont acceptées ; les capacités du compilateur ne sont étendues que lorsque leur sémantique peut être représentée et validée.