PostgreSQL vynutí standardní syntaxi SQL

PostgreSQL žádnou takovou funkci nemá. I kdyby tomu tak bylo, nepomohlo by vám to, protože interpretace standardu SQL se liší, podpora standardní syntaxe a funkcí se liší a některé DB jsou uvolněné ohledně omezení, která ostatní vynucují, nebo mají omezení, která ostatní nemají. Syntaxe je nejmenší z vašich problémů.

Jediným spolehlivým způsobem, jak napsat přenositelný SQL mezi DB, je otestovat tento SQL v každé cílové databázi v rámci sady automatických testů . A hodně nadávat.

Na mnoha místech analyzátor/přepisovač dotazů transformuje standardní „hláskování“ dotazu do interního formuláře PostgreSQL, který bude vygenerován při výpisu/znovu načtení. PostgreSQL zejména neukládá nezpracovaný zdrojový kód pro věci, jako jsou pohledy, kontrolní omezující výrazy, indexové výrazy atd. Ukládá vnitřní strom analýzy a rekonstruuje z něj zdroj, když je požádán o výpis nebo zobrazení objektu.

Například:

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)

Stejně by to bylo docela k ničemu, protože standard neuvádí některé docela běžné a důležité funkce a často má dost nejednoznačné specifikace věcí, které definuje. Až donedávna nedefinoval způsob, jak omezit počet řádků vrácených například dotazem, takže každá databáze měla svou vlastní odlišnou syntaxi (TOP , LIMIT / OFFSET , atd.).

Ostatní věci, které standard specifikuje, většina prodejců neimplementuje, takže jejich používání je celkem zbytečné. Hodně štěstí při používání sloupců generovaných standardem SQL a identit u všech dodavatelů DB.

Bylo by docela hezké mít režim výpisu „preferovat standardní pravopis“, který by používal CAST místo :: , atd., ale to opravdu není jednoduché, protože některé transformace nejsou 1:1 reverzibilní, např.:

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

nebo:

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;

takže vidíte, že by bylo třeba provést významné změny v tom, jak PostgreSQL interně reprezentuje a pracuje s funkcemi a výrazy, než bude možné to, co chcete.

Spousta standardních věcí SQL používá funky jednorázovou syntaxi, kterou PostgreSQL převádí na volání funkcí a přetypovává během analýzy, takže nemusí přidávat speciální vlastnosti případu pokaždé, když má SQL Comite další mozek a vytáhne nějaký nový kreativní kousek. syntaxe odněkud... Změna by vyžadovala přidání spousty nových typů výrazových uzlů a obecný nepořádek, to vše bez skutečného zisku.