PostgreSQL hat keine solche Funktion. Selbst wenn dies der Fall wäre, würde es Ihnen nicht viel helfen, da die Interpretationen des SQL-Standards unterschiedlich sind, die Unterstützung für Standardsyntax und -funktionen unterschiedlich ist und einige DBs Einschränkungen gegenüber locker sind, die andere durchsetzen, oder Einschränkungen haben, die andere nicht haben. Syntax ist Ihr geringstes Problem.
Der einzig zuverlässige Weg, datenbankübergreifendes portables SQL zu schreiben, besteht darin, dieses SQL auf jeder Zieldatenbank als Teil einer automatisierten Testsuite zu testen . Und viel fluchen.
An vielen Stellen wandelt der Abfrage-Parser/Umschreiber die Standard-"Schreibweise" einer Abfrage in die interne PostgreSQL-Form um, die beim Dump/Reload ausgegeben wird. Insbesondere speichert PostgreSQL nicht den rohen Quellcode für Dinge wie Views, Check-Constraint-Ausdrücke, Index-Ausdrücke usw. Es speichert den internen Parsing-Baum und rekonstruiert die Quelle daraus, wenn es aufgefordert wird, das Objekt auszugeben oder anzuzeigen.
Zum Beispiel:
regress=> CREATE TABLE sometable ( x varchar(100) );
CREATE TABLE
regress=> CREATE VIEW someview AS SELECT CAST (x AS integer) FROM sometable;
CREATE VIEW
regress=> SELECT pg_get_viewdef('someview');
pg_get_viewdef
-------------------------------------
SELECT (sometable.x)::integer AS x
FROM sometable;
(1 row)
Es wäre sowieso ziemlich nutzlos, da der Standard einige ziemlich häufige und wichtige Teile der Funktionalität nicht spezifiziert und oft ziemlich zweideutige Spezifikationen von Dingen hat, die er definiert. Bis vor kurzem hat es beispielsweise keine Möglichkeit definiert, die Anzahl der von einer Abfrage zurückgegebenen Zeilen zu begrenzen, sodass jede Datenbank ihre eigene unterschiedliche Syntax hatte (TOP , LIMIT / OFFSET usw.).
Andere Dinge, die der Standard spezifiziert, werden von den meisten Anbietern nicht implementiert, daher ist ihre Verwendung ziemlich sinnlos. Viel Glück bei der Verwendung der vom SQL-Standard generierten und Identitätsspalten bei allen DB-Anbietern.
Es wäre ganz nett, einen "Standardschreibweise bevorzugen"-Dump-Modus zu haben, der CAST verwendet statt :: , usw., aber es ist wirklich nicht einfach, weil einige Transformationen nicht 1:1 umkehrbar sind, z. B.:
regress=> CREATE VIEW v AS SELECT '1234' SIMILAR TO '%23%';
CREATE VIEW
regress=> SELECT pg_get_viewdef('v');
SELECT ('1234'::text ~ similar_escape('%23%'::text, NULL::text));
oder:
regress=> CREATE VIEW v2 AS SELECT extract(dow FROM current_date);
CREATE VIEW
regress=> SELECT pg_get_viewdef('v2');
SELECT date_part('dow'::text, ('now'::text)::date) AS date_part;
Sie sehen also, dass erhebliche Änderungen daran vorgenommen werden müssten, wie PostgreSQL intern Funktionen und Ausdrücke darstellt und mit ihnen arbeitet, bevor das, was Sie wollen, möglich wäre.
Ein Großteil des SQL-Standard-Zeugs verwendet eine unkonventionelle Einmal-Syntax, die PostgreSQL während des Parsens in Funktionsaufrufe und Umwandlungen umwandelt, sodass nicht jedes Mal, wenn das SQL-Commite einen weiteren Hirnfurz hat und ein neues kreatives Bit herausholt, Sonderfallfunktionen hinzugefügt werden müssen der Syntax aus ... irgendwo. Das zu ändern würde das Hinzufügen von Tonnen neuer Ausdrucksknotentypen und allgemeines Durcheinander erfordern, alles ohne wirklichen Gewinn.
