Begrenzte Kompilierung und Schemanachweise
Die Kompilierung weist Eingaben über 4,194,304 UTF-16-Einheiten, 131,072 lexikalischen Token ohne End, 8,192 Gruppierungsebenen oder 65,536 AST-Knoten ab. Iterative AST-Traversierung und begrenzte Ausgabe bewahren Parameterreihenfolge und Ablehnung bei unzureichendem Sicherheitsnachweis für alle sechs Provider. Beliebige SQL-Tiefe wird nicht garantiert.
Die Budgets betragen 8,000,000 Arbeitseinheiten je Phase, 32,000,000 je Kompilierung, 30 Sekunden je Phase, 90 Sekunden insgesamt und 536,870,912 kumulativ allokierte verwaltete Bytes je Phase. Dies sind Compilerbudgets, keine DB-Abfragezeitlimits oder Prozessspeichergrenzen. Typisierte Ressourcendiagnosen melden Überschreitungen.
Ein optionaler unveränderlicher Schemasnapshot löst Tabellen-/Spaltennamen und nachweisbare Typfamilien auf, einschließlich geordneter CTE-/abgeleiteter Projektionen. Sein Digest wird an den Planfingerabdruck gebunden. Das ist kein vollständiger DB-Typprüfer. DML mit Schemanachweis benötigt eine aktuelle Frischeprüfung; fehlende oder geänderte Nachweise führen zur Ablehnung. Standardmäßig wird kein Snapshot erfasst. AddHsSqlAgentNativeDmlSchemaFreshness() aktiviert die optionale native Unterstützung.
hs-sql-agent behandelt generiertes SQL nicht als vertrauenswürdigen Befehl. Die Ausführungsgrenze ist um Parsing, Validierung, Fähigkeitsprüfungen, Zugriffsrichtlinien und datenbankspezifische Kompilierung aufgebaut.
Abfragepfad
Auf hoher Ebene durchläuft eine Abfrage diese Schritte:
- MCP-Schlüssel authentifizieren und seinen Datenbank-, Tabellen-, Werkzeug- und Ausführungsumfang anwenden.
- Unterstütztes SQL in eine strukturierte Definition / AST parsen.
- Die Anweisung und ihre unterstützte Quellsemantik validieren.
- Die Zielfähigkeiten prüfen, die zum Erhalt dieser Semantik erforderlich sind.
- SQL für die konfigurierte Datenbank kompilieren und ausgeben.
- Innerhalb der konfigurierten Laufzeitgrenzen ausführen.
Die Implementierung des SQL-Compilers enthält explizite Stufen für Quellvalidierung und Zielfähigkeiten. Nicht unterstützte Syntax oder eine Fähigkeit, deren Gleichwertigkeit nicht nachgewiesen werden kann, wird abgelehnt, statt stillschweigend durch eine oberflächlich ähnliche Konstruktion ersetzt zu werden.
Warum bei Unsicherheit ablehnen?
Datenbankübergreifendes SQL enthält viele Konstruktionen, die gleich aussehen, sich aber bei NULL, Typregeln, Operatorsemantik, Pagination, Bezeichnern, Funktionen oder DML-Verhalten unterscheiden.
Für eine KI-nahe Ausführungsoberfläche ist ein Umschreiben nach dem Prinzip „best effort“ gefährlich: Eine Anweisung kann syntaktisch gültig bleiben und trotzdem ihre Bedeutung ändern. hs-sql-agent bevorzugt deshalb eine sichtbare Ablehnung gegenüber einer stillen semantischen Abschwächung. Dieses Verhalten entspricht dem Fail-Closed-Prinzip.
Datenbankspezifische Ausgabe
Die öffentliche MCP-Schnittstelle ist gemeinsam, das endgültige SQL jedoch datenbankspezifisch. Derzeit werden folgende Datenbanken unterstützt:
- PostgreSQL
- MySQL
- SQL Server
- Oracle
- SQLite
- Firebird
Der unterstützte Umfang ist absichtlich begrenzt. Dass eine Datenbank unterstützt wird, bedeutet nicht, dass jede von ihr angebotene SQL-Syntax akzeptiert wird; einzelne Compiler-Fähigkeiten werden erst erweitert, wenn ihre Semantik repräsentiert und validiert werden kann.