PostgreSQL tvingar standard SQL-syntax

PostgreSQL har ingen sådan funktion. Även om det gjorde det, skulle det inte hjälpa dig massor eftersom tolkningarna av SQL-standarden varierar, stödet för standardsyntax och funktioner varierar, och vissa DB:er är avslappnade när det gäller begränsningar som andra tillämpar eller har begränsningar som andra inte har. Syntax är det minsta av dina problem.

Det enda tillförlitliga sättet att skriva över DB-portabel SQL är att testa denna SQL på varje måldatabas som en del av en automatiserad testsvit . Och att svära mycket.

På många ställen omvandlar frågeparser/rewriter standard "stavning" för en fråga till den interna PostgreSQL-formen, som kommer att sändas ut vid dumpning/återladdning. PostgreSQL lagrar i synnerhet inte den råa källkoden för saker som vyer, kontrollbegränsningsuttryck, indexuttryck etc. Det lagrar det interna analysträdet och rekonstruerar källan från det när den ombeds att dumpa eller visa objektet.

Till exempel:

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)

Det skulle vara ganska värdelöst i alla fall, eftersom standarden inte specificerar några ganska vanliga och viktiga delar av funktionalitet och ofta har ganska tvetydiga specifikationer för saker som den definierar. Tills nyligen har det inte definierat något sätt att begränsa antalet rader som returneras av en fråga, till exempel, så varje databas hade sin egen olika syntax (TOP , LIMIT / OFFSET , etc).

Andra saker som standarden anger implementeras inte av de flesta leverantörer, så att använda dem är ganska meningslöst. Lycka till med att använda SQL-standarden och identitetskolumner för alla DB-leverantörer.

Det skulle vara ganska trevligt att ha ett dumpläge "föredrar standardstavning", som använde CAST istället för :: , etc, men det är verkligen inte enkelt att göra eftersom vissa transformationer inte är reversibla 1:1, t.ex.:

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));

eller:

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;

så du ser att betydande förändringar skulle behöva göras i hur PostgreSQL internt representerar och arbetar med funktioner och uttryck innan det du vill skulle vara möjligt.

Många av SQL-standardsakerna använder funky engångssyntax som PostgreSQL konverterar till funktionsanrop och casts under analys, så det behöver inte lägga till speciella fallfunktioner varje gång SQL-kommitten har en annan hjärnfiss och drar någon ny kreativ bit av syntax från ... någonstans. Att ändra som skulle kräva att man lägger till massor av nya uttrycksnodtyper och allmän röra, allt utan någon verklig vinst.