PostgreSQL n'a pas une telle fonctionnalité. Même si c'était le cas, cela ne vous aiderait pas beaucoup car les interprétations de la norme SQL varient, la prise en charge de la syntaxe et des fonctionnalités standard varie, et certaines bases de données sont assouplies sur les restrictions que d'autres appliquent ou ont des limitations que d'autres n'ont pas. La syntaxe est le moindre de vos problèmes.
Le seul moyen fiable d'écrire du SQL portable inter-DB est de tester ce SQL sur chaque base de données cible dans le cadre d'une suite de tests automatisés . Et beaucoup jurer.
Dans de nombreux endroits, l'analyseur/réécriture de requêtes transforme l'"orthographe" standard d'une requête dans la forme interne de PostgreSQL, qui sera émise lors du vidage/rechargement. En particulier, PostgreSQL ne stocke pas le code source brut pour des éléments tels que les vues, les expressions de contrainte de vérification, les expressions d'index, etc. Il stocke l'arbre d'analyse interne et reconstruit la source à partir de celle-ci lorsqu'il est demandé de vider ou d'afficher l'objet.
Par exemple :
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)
Ce serait assez inutile de toute façon, car la norme ne spécifie pas certaines fonctionnalités assez courantes et importantes et a souvent des spécifications plutôt ambiguës sur les choses qu'elle définit. Jusqu'à récemment, il ne définissait pas de moyen de limiter le nombre de lignes renvoyées par une requête, par exemple, de sorte que chaque base de données avait sa propre syntaxe différente (TOP , LIMIT / OFFSET , etc.).
D'autres choses que la norme spécifie ne sont pas implémentées par la plupart des fournisseurs, donc les utiliser est assez inutile. Bonne chance pour utiliser les colonnes d'identité et générées au standard SQL sur tous les fournisseurs de bases de données.
Ce serait plutôt bien d'avoir un mode de vidage "préférer l'orthographe standard", qui utilise CAST au lieu de :: , etc, mais ce n'est vraiment pas simple à faire car certaines transformations ne sont pas réversibles 1:1, par exemple :
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));
ou :
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;
vous voyez donc que des changements importants devraient être apportés à la façon dont PostgreSQL représente et fonctionne en interne avec les fonctions et les expressions avant que ce que vous voulez ne soit possible.
Beaucoup de choses standard SQL utilisent une syntaxe unique et géniale que PostgreSQL convertit en appels de fonction et les lance pendant l'analyse, de sorte qu'il n'a pas besoin d'ajouter des fonctionnalités de cas spéciaux chaque fois que le comité SQL a un autre pet de cerveau et tire un nouveau peu créatif de syntaxe hors de ... quelque part. Changer cela nécessiterait d'ajouter des tonnes de nouveaux types de nœuds d'expression et de désordre général, le tout sans réel gain.
