PostgreSQL heeft zo'n functie niet. Zelfs als dat zo was, zou het je niet veel helpen omdat interpretaties van de SQL-standaard variëren, ondersteuning voor standaardsyntaxis en functies variëren, en sommige DB's zijn ontspannen over beperkingen die anderen afdwingen of beperkingen hebben die anderen niet hebben. Syntaxis is het minste van je problemen.
De enige betrouwbare manier om cross-DB draagbare SQL te schrijven, is door die SQL op elke doeldatabase te testen als onderdeel van een geautomatiseerde testsuite . En om veel te vloeken.
Op veel plaatsen transformeert de query-parser/rewriter de standaard "spelling" van een query in de interne PostgreSQL-vorm, die wordt uitgezonden bij dump/reload. In het bijzonder slaat PostgreSQL de onbewerkte broncode niet op voor zaken als views, check constraint-expressies, index-expressies, enz. Het slaat de interne ontledingsboom op en reconstrueert de bron daaruit wanneer wordt gevraagd om het object te dumpen of weer te geven.
Bijvoorbeeld:
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)
Het zou hoe dan ook behoorlijk nutteloos zijn, aangezien de standaard er niet in slaagt een aantal vrij algemene en belangrijke functionaliteiten te specificeren en vaak nogal dubbelzinnige specificaties heeft van dingen die het wel definieert. Tot voor kort definieerde het bijvoorbeeld geen manier om het aantal rijen dat door een query wordt geretourneerd te beperken, dus elke database had zijn eigen andere syntaxis (TOP , LIMIT / OFFSET , enz.).
Andere dingen die de standaard specificeert, worden door de meeste leveranciers niet geïmplementeerd, dus het gebruik ervan is vrij zinloos. Veel succes met het gebruik van de door SQL-standaard gegenereerde kolommen en identiteitskolommen voor alle DB-leveranciers.
Het zou heel leuk zijn om een dumpmodus met "voorkeur voor standaard spelling" te hebben, die gebruikmaakt van CAST in plaats van :: , enz., maar het is echt niet eenvoudig om te doen, omdat sommige transformaties niet 1:1 omkeerbaar zijn, bijvoorbeeld:
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));
of:
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;
dus je ziet dat er belangrijke veranderingen moeten worden aangebracht in hoe PostgreSQL intern functies en expressies vertegenwoordigt en ermee werkt voordat wat je wilt mogelijk zou zijn.
Veel van de standaard SQL-dingen gebruiken een funky eenmalige syntaxis die PostgreSQL tijdens het parseren omzet in functieaanroepen en casts, dus het hoeft geen speciale case-functies toe te voegen telkens wanneer de SQL-commissie weer een hersenscheet heeft en een nieuw creatief stukje trekt van syntaxis uit ... ergens. Om dat te veranderen zou het nodig zijn tonnen nieuwe typen expressieknooppunten en algemene rotzooi toe te voegen, allemaal zonder echte winst.