Einen SQL-Compiler für mehrere Dialekte erweitern, ohne die Bedeutung der Abfragen zu ändern

## Vor dem Ändern die zuständige Schicht des Compilers finden Behandeln Sie das System als Compiler, dessen Schichten unterschiedliche Zuständigkeiten besitzen: - der Tokenisierer wandelt SQL-Text in typisierte Token um und lässt Dialekte lexikalische Zuordnungen überschreiben; - der Parser baut durch rekursiven Abstieg einen abstrakten Syntaxbaum (AST) auf und verwendet dafür eigene Abgleichs-, Cursor-, Listen- und Hüllenhilfen; - Ausdrucksklassen stellen semantische SQL-Konzepte dar und unterstützen Durchlauf und Transformation; - der Generator wandelt Ausdrücke rekursiv zurück in SQL und nutzt dafür einfache Transformationszuordnungen oder eigene Erzeugungsmethoden; - Dialektmodule erweitern eine gemeinsame Grundlage um Funktionsmerkmale, Tokenmengen sowie Zuordnungen für Analyse und Erzeugung; - Optimierungsregeln vereinheitlichen und verändern den AST in einer bewusst festgelegten Reihenfolge; - Schema- und Typinformationen unterstützen Optimierung, Transpilierung und Datenherkunft; - die Datenherkunft verbindet Ausgabespalten mit vorgelagerten Ausdrücken und Tabellen. Ermitteln Sie die zuständige Schicht, bevor Sie Verhalten ändern. Halten Sie Tokenisierung, Analyse, semantische Darstellung, Optimierung und Erzeugung getrennt, statt eine Schicht zu reparieren, indem Logik in eine andere durchsickert. Bewahren Sie die Symmetrie von Parser und Generator: Die Analyse ordnet Token Ausdrücken zu, während die Erzeugung Ausdrücke in SQL überführt. Wenn der Parser bei unbekanntem Text absichtlich auf einen allgemeinen Befehlsknoten zurückfällt, verwandeln Sie diesen Erhaltungsmechanismus nicht stillschweigend in eine Teilanalyse. ## Die Test- und Prüfbefehle des Repositorys für reine und native Umsetzung nutzen Lesen Sie vor Änderungen die Beitrags- und Architekturhinweise des Repositorys. Verwenden Sie die dokumentierten Ziele für Grundinstallation, Entwicklungsinstallation, Installation einer optionalen nativen Erweiterung, Einrichtung der Prüfungen vor Commits, vollständige Tests, Komponententests, Stilprüfungen, Typprüfungen und Leistungsvergleiche. Unterscheiden Sie die reine Hochsprachenimplementierung von einer optionalen kompilierten Erweiterung. Führen Sie zuerst den unmittelbar relevanten Modus und anschließend die durch die Änderung erforderlichen umfassenderen Prüfungen aus. Wenn native Beschleunigung betroffen ist, prüfen Sie sowohl die reine Implementierung als auch den kompilierten Pfad, statt identisches Verhalten vorauszusetzen. Grenzen Sie Fehler während der Bearbeitung genau ein, indem Sie eine bestimmte Testdatei, Klasse oder Methode ausführen. Führen Sie vor der Einreichung das vollständige vorgeschriebene Prüfziel des Repositorys aus, einschließlich Formatierung, statischer Prüfungen, Tests der reinen Laufzeit und gegebenenfalls Tests der nativen Erweiterung. Verwenden Sie bei leistungssensiblen Arbeiten Leistungsvergleiche für Analyse und Optimierung. Vergleichen Sie gleichartige Konfigurationen und opfern Sie semantische Korrektheit nicht zugunsten eines guten Mikrovergleichswerts. ## Beim Übertragen von SQL in einen anderen Dialekt dieselbe Bedeutung behalten Behandeln Sie den AST als semantische Wahrheitsquelle. Analysieren Sie Quell-SQL zu semantischen Ausdrücken und erzeugen Sie aus diesen den Zieldialekt; bewahren Sie die Bedeutung und nicht die Schreibweise der Quelle. Kommentare dürfen nach bestem Bemühen erhalten bleiben, doch semantische Gleichwertigkeit hat Vorrang. Fügen Sie Funktionalitäten, die mehrere Dialekte gemeinsam nutzen, nur dann der gemeinsamen Grundlage hinzu, wenn ihre Semantik tatsächlich übereinstimmt. Ergänzen Sie dialektspezifische Syntax oder Verhalten ausschließlich im betreffenden Dialekt. Verwenden Sie ausdrückliche Funktionsschalter, Mengen reservierter Token, Funktions- oder Anweisungszuordnungen und Ausdruck-zu-SQL-Zuordnungen statt verstreuter Namensprüfungen. Belassen Sie Optimierungsregeln in ihrer beabsichtigten Reihenfolge. Qualifizierung, Typanreicherung, Vorverlagerung von Prädikaten oder Projektionen und Vereinfachung können von früheren Schritten und Schemainformationen abhängen. Behandeln Sie den Optimierer als logische Umformung und nicht als physischen Abfrageplaner. Wenn eine Funktion von der Datenbankstruktur abhängt, stellen Sie Schemainformationen ausdrücklich bereit. Behaupten Sie keine zuverlässige Qualifizierung, Typableitung, Optimierung oder Spaltenherkunft, wenn die erforderlichen Tabellen- und Spaltenmetadaten fehlen. ## SQL mit AST-Hilfsfunktionen und Vorlagen bauen statt Zeichenketten zusammenzusetzen Suchen Sie vor dem Anlegen eines allgemeinen Funktionsausdrucks im Ausdruckskatalog nach einer vorhandenen spezialisierten Klasse. Verwenden Sie einen allgemeinen anonymen Ausdruck nur, wenn keine spezialisierte semantische Klasse existiert. Bevorzugen Sie den einfachsten unterstützten Erzeugungsmechanismus: 1. Implementieren Sie für einen einzelnen komplexen Ausdruckstyp die automatisch erkannte Generatormethode `<lowercase_expression_name>_sql`. 2. Verwenden Sie Transformationszuordnungen ausschließlich für einfache einzeilige Umbenennungen, Lambdas oder Funktionen, die absichtlich mehrere Einstiegspunkte besitzen. 3. Nutzen Sie innerhalb von Generatormethoden die Funktionshilfe des Generators, statt einen Funktionsknoten nur für seine Serialisierung zu erzeugen. 4. Verwenden Sie Ausdruckserzeuger und Operatoren für Arrays, boolesche Ausdrücke, Fallunterscheidungen, Typumwandlungen, Spalten, Nullwerte, Arithmetik, Indizierung und Vergleiche. 5. Analysieren Sie bei komplexer Ausgabe eine SQL-Vorlage und ersetzen Sie Platzhalter in einer Kopie des AST. Setzen Sie SQL-Fragmente nicht mit Zeichenketteninterpolation zusammen. AST-Erzeuger und Vorlagen bewahren Anführungszeichen, Maskierung, Verschachtelung und Dialektverhalten, die bei manuell aufgebauten Zeichenketten häufig beschädigt werden. ## Typen erst nach der Typannotation prüfen und NULL zur Laufzeit behandeln Unterscheiden Sie syntaktische und semantische Typprüfungen. Verwenden Sie ein Literalprädikat wie `is_string` nur, wenn Sie prüfen, ob ein Knoten tatsächlich ein Zeichenkettenliteral ist, und dessen Literalwert auslesen. Verwenden Sie `is_type()`, wenn Sie den abgeleiteten semantischen Typ einer Spalte, eines Funktionsergebnisses oder eines anderen Ausdrucks prüfen. Wenn semantisches Verhalten von Typen abhängt, führen Sie die Typanreicherung vor dem Aufruf von `is_type()` aus. Tests für typabhängige Transpilierung müssen den AST mit Typen anreichern; andernfalls kann eine korrekte semantische Prüfung scheinbar fehlschlagen, weil der Typ nie eingetragen wurde. Verwenden Sie nach der Bestätigung, dass ein Knoten ein numerisches Literal ist, dessen Konvertierungsmethode wie `to_py()`, um den Zahlenwert auszulesen. Entfernen Sie Anführungszeichen nicht manuell und wandeln Sie keinen internen Rohtext direkt um. Lösen Sie das Verhalten von SQL-`NULL` nicht während der Transpilierung, indem Sie nur auf einen literalen Nullknoten prüfen. Erzeugen Sie SQL mit einer Laufzeitprüfung durch `IS NULL`, damit Spalten, Parameter, Ausdrücke und literale Nullwerte derselben Semantik folgen. Beziehen Sie bei der Suche nach Vorfahren Abfragegrenzen ein, damit die Suche nicht in eine übergeordnete Abfrage entweicht. Verwenden Sie den Deklarationsmechanismus des Systems für nicht unterstützte Argumente, wenn ein Zieldialekt bestimmte Argumente nicht darstellen kann. ## Jeden Dialekt testen und die Tests gegen echte Datenbanken laufen lassen Fügen Sie Tests der Testsammlung hinzu, die für den betroffenen Dialekt oder die betroffene Compilerschicht zuständig ist. Verwenden Sie Rundlaufprüfungen für Syntax, die unverändert bleiben soll, und dialektübergreifende Prüfungen, wenn ein semantischer Ausdruck in verschiedenen Zieldialekten unterschiedliches SQL erzeugen muss. Verdoppeln Sie keine Abdeckung, die dasselbe Verhalten bereits belegt. Ergänzen Sie gezielte Fälle für die neue semantische Unterscheidung, einschließlich Nullfähigkeit, Typen, Anführungszeichen, Geltungsbereich, nicht unterstützter Argumente oder Dialektunterschiede, sofern diese einschlägig sind. Stellen Sie sicher, dass Tests in datenbankspezifischen Testsammlungen tatsächlich gegen die jeweiligen Datenbanken oder kompatible Ausführungsumgebungen laufen. Eine erzeugte Zeichenkette allein ist kein Beweis, wenn die Regel vom Laufzeitverhalten abhängt. Prüfen Sie bei typabhängiger Ausgabe sowohl Literale als auch typisierte Ausdrücke, die keine Literale sind. Bestätigen Sie bei nativer Beschleunigung die Übereinstimmung mit der reinen Implementierung. Nehmen Sie bei Änderungen am Optimierer schemaabhängige Fälle auf und prüfen Sie, dass die Regelreihenfolge die Bedeutung nicht verändert. ## Jede Änderung auf einen Zweck beschränken und leicht prüfbar halten Begrenzen Sie jede Änderung auf einen klar definierten Zweck. Ergänzen Sie Tests für nicht triviales Verhalten, aktualisieren Sie öffentliche Dokumentationszeichenketten bei API-Änderungen, befolgen Sie die Konventionen des Repositorys für Änderungsanträge und Commits und führen Sie vor der Einreichung alle vorgeschriebenen Prüfungen aus. Entfernen Sie ungenutzte Importe, Variablen und nicht mehr verwendeten Code. Vermeiden Sie Kompatibilitätshilfen für absichtlich entfernten Code. Bevorzugen Sie einen lesbaren eingebetteten Ausdruck gegenüber einer unnötigen temporären Variable, verdichten Sie die Logik jedoch nicht so weit, dass ihre semantischen Phasen unklar werden. Verwenden Sie Kommentare nur für nicht offensichtliche Logik und fügen Sie Dokumentationszeichenketten nur für komplexes Verhalten oder öffentliche APIs hinzu. Ändern Sie weder Lizenzdateien noch Lizenzkonfigurationen, sofern die Aufgabe nicht ausdrücklich die Lizenzierung betrifft. Prüfen Sie die Änderung auf unbeabsichtigte Dialektkopplung, doppelte Ausdruckstypen, manuell aufgebautes SQL, fehlende Typanreicherung, ausschließlich zur Übersetzungszeit behandeltes Nullverhalten, entweichende Geltungsbereiche und ungeprüftes natives oder datenbankspezifisches Verhalten. ## Beim Beschleunigen den nativen Pfad und den Aufbau des Parsers erhalten Behandeln Sie Leistung als Produkteigenschaft, auch wenn die Hauptimplementierung eine Hochsprache verwendet. Bewahren Sie optionale native Beschleunigungspfade und messen Sie Änderungen, die Tokenisierung, Analyse, Erzeugung oder Optimierung beeinflussen. Ersetzen Sie einen absichtlich gewählten Parser mit rekursivem Abstieg nicht durch Pratt-Analyse, weil Sie darin eine vermeintliche Optimierung sehen. Die Analysestrategie ist eine Architekturentscheidung und keine austauschbare Geschwindigkeitseinstellung. Vermeiden Sie Abstraktionen, von denen bekannt ist, dass sie den kompilierten Pfad beeinträchtigen, wenn die Codebasis eine bevorzugte Alternative dokumentiert, etwa einfache Vereinigungstypen und strukturelles Duck-Typing statt einer nicht unterstützten Protokollabstraktion. Optimieren Sie erst, nachdem Korrektheit über Analyse, AST-Aufbau, Erzeugung, Dialektverhalten und Tests hinweg bewahrt ist. Eine schnellere Implementierung, die Semantik verändert, Anführungszeichen verliert, `NULL` falsch behandelt oder zwischen reinem und kompiliertem Modus abweicht, ist eine Regression.