PostgreSQLは標準のSQL構文を強制します

PostgreSQLにはそのような機能はありません。たとえそうだったとしても、SQL標準の解釈が異なり、標準の構文と機能のサポートが異なり、一部のDBは、他のDBが強制する制限や、他のDBが適用しない制限について緩和されているため、あまり役に立ちません。構文はあなたの問題の中で最も少ないです。

クロスDBポータブルSQLを作成する唯一の信頼できる方法は、自動テストスイートの一部としてすべてのターゲットデータベースでそのSQLをテストすることです。 。そして、多くのことを誓います。

多くの場所で、クエリパーサー/リライターはクエリの標準の「スペル」をPostgreSQLの内部形式に変換します。これは、ダンプ/リロード時に発行されます。特に、PostgreSQLは、ビュー、チェック制約式、インデックス式などの生のソースコードを保存しません。内部解析ツリーを保存し、オブジェクトのダンプまたは表示を求められたときに、そこからソースを再構築します。

例：

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)

とにかく、標準はかなり一般的で重要な機能の一部を指定できず、定義するものの仕様がかなりあいまいであることが多いため、かなり役に立たないでしょう。たとえば、最近まで、クエリによって返される行数を制限する方法が定義されていなかったため、データベースごとに独自の異なる構文（ TOP ）がありました。 、 LIMIT /オフセット など）。

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

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;