PostgreSQL fremtvinger standard SQL-syntaks

PostgreSQL har ingen sådan funktion. Selvom det gjorde det, ville det ikke hjælpe dig meget, fordi fortolkninger af SQL-standarden varierer, understøttelse af standardsyntaks og funktioner varierer, og nogle DB'er er afslappede med hensyn til begrænsninger, som andre håndhæver eller har begrænsninger, andre ikke har. Syntaks er det mindste af dine problemer.

Den eneste pålidelige måde at skrive bærbar SQL på tværs af DB er at teste den SQL på hver måldatabase som en del af en automatiseret testpakke . Og at bande meget.

Mange steder transformerer forespørgselsparseren/rewriteren standard "stavning" af en forespørgsel til den interne PostgreSQL-form, som vil blive udsendt ved dump/genindlæsning. Navnlig gemmer PostgreSQL ikke den rå kildekode til ting som visninger, tjekbegrænsningsudtryk, indeksudtryk osv. Det gemmer det interne parsetræ og rekonstruerer kilden ud fra det, når det bliver bedt om at dumpe eller vise objektet.

For eksempel:

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 ville alligevel være ret ubrugeligt, da standarden ikke specificerer nogle ret almindelige og vigtige dele af funktionalitet og ofte har ret tvetydige specifikationer af ting, den definerer. Indtil for nylig har den ikke defineret en måde at begrænse antallet af rækker, der returneres af en forespørgsel, for eksempel, så hver database havde sin egen forskellige syntaks (TOP , LIMIT / OFFSET osv.).

Andre ting, som standarden specificerer, implementeres ikke af de fleste leverandører, så det er ret meningsløst at bruge dem. Held og lykke med at bruge de SQL-standardgenererede og identitetskolonner på tværs af alle DB-leverandører.

Det ville være ret rart at have en "foretrækker standardstavning" dump-tilstand, der brugte CAST i stedet for :: osv., men det er virkelig ikke nemt at gøre, fordi nogle transformationer ikke er 1:1 reversible, f.eks.:

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 kan se, at der skal foretages væsentlige ændringer i, hvordan PostgreSQL internt repræsenterer og arbejder med funktioner og udtryk, før det, du ønsker, ville være muligt.

Mange af SQL-standard-tingene bruger funky engangssyntaks, som PostgreSQL konverterer til funktionskald og casts under parsing, så det ikke behøver at tilføje specielle case-funktioner, hver gang SQL-committen har en anden hjerne-prut og trækker noget nyt kreativt bit. af syntaks ud af ... et eller andet sted. Ændring af det ville kræve at tilføje tonsvis af nye udtryksknudetyper og generelt rod, alt sammen uden reel gevinst.