PostgreSQL tidak memiliki fitur seperti itu. Bahkan jika ya, itu tidak akan banyak membantu Anda karena interpretasi standar SQL bervariasi, dukungan untuk sintaks dan fitur standar bervariasi, dan beberapa DB santai tentang batasan yang diberlakukan orang lain atau memiliki batasan yang tidak dimiliki orang lain. Sintaks adalah masalah Anda yang paling kecil.
Satu-satunya cara yang dapat diandalkan untuk menulis SQL portabel lintas-DB adalah dengan menguji SQL tersebut pada setiap database target sebagai bagian dari rangkaian pengujian otomatis . Dan banyak bersumpah.
Di banyak tempat, parser/penulis ulang kueri mengubah "ejaan" standar kueri ke dalam bentuk internal PostgreSQL, yang akan dikeluarkan saat dump/reload. Secara khusus, PostgreSQL tidak menyimpan kode sumber mentah untuk hal-hal seperti tampilan, memeriksa ekspresi batasan, ekspresi indeks, dll. PostgreSQL menyimpan pohon parse internal, dan merekonstruksi sumber dari itu ketika diminta untuk membuang atau menampilkan objek.
Misalnya:
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)
Bagaimanapun, itu akan sangat tidak berguna, karena standar gagal menentukan beberapa fungsi yang cukup umum dan penting dan seringkali memiliki spesifikasi yang agak ambigu dari hal-hal yang ditentukannya. Sampai saat ini tidak mendefinisikan cara untuk membatasi jumlah baris yang dikembalikan oleh kueri, misalnya, jadi setiap database memiliki sintaks yang berbeda (TOP , LIMIT / OFFSET , dll).
Hal-hal lain yang ditentukan oleh standar tidak diterapkan oleh sebagian besar vendor, jadi menggunakannya tidak ada gunanya. Semoga berhasil menggunakan kolom identitas dan standar SQL yang dihasilkan di semua vendor DB.
Akan cukup bagus untuk memiliki mode dump "lebih suka ejaan standar", yang menggunakan CAST bukannya :: , dll, tetapi sebenarnya tidak mudah dilakukan karena beberapa transformasi tidak dapat dibalikkan 1:1, mis.:
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));
atau:
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;
jadi Anda melihat bahwa perubahan signifikan perlu dilakukan pada bagaimana PostgreSQL secara internal mewakili dan bekerja dengan fungsi dan ekspresi sebelum apa yang Anda inginkan menjadi mungkin.
Banyak hal standar SQL menggunakan sintaksis satu kali yang funky yang diubah PostgreSQL menjadi panggilan fungsi dan gips selama penguraian, sehingga tidak perlu menambahkan fitur kasus khusus setiap kali komite SQL memiliki brain-fart lain dan menarik beberapa kreatif baru. sintaks dari ... di suatu tempat. Mengubahnya akan membutuhkan penambahan banyak jenis simpul ekspresi baru dan kekacauan umum, semuanya tanpa keuntungan nyata.
