PostgreSQL không có tính năng này. Ngay cả khi nó đã làm, nó sẽ không giúp bạn nhiều vì các diễn giải của tiêu chuẩn SQL khác nhau, hỗ trợ cho cú pháp và tính năng tiêu chuẩn khác nhau và một số DB được nới lỏng về các hạn chế mà những người khác thực thi hoặc có những hạn chế mà những người khác không. Cú pháp là vấn đề nhỏ nhất trong số các vấn đề của bạn.
Cách đáng tin cậy duy nhất để viết SQL di động chéo DB là kiểm tra SQL đó trên mọi cơ sở dữ liệu đích như một phần của bộ kiểm tra tự động . Và thề thật nhiều.
Ở nhiều nơi, trình phân tích cú pháp / viết lại truy vấn chuyển đổi "chính tả" tiêu chuẩn của truy vấn thành dạng nội bộ PostgreSQL, dạng này sẽ được phát ra khi kết xuất / tải lại. Đặc biệt, PostgreSQL không lưu trữ mã nguồn thô cho những thứ như chế độ xem, kiểm tra biểu thức ràng buộc, biểu thức chỉ mục, v.v. Nó lưu trữ cây phân tích cú pháp nội bộ và cấu trúc lại nguồn từ đó khi nó được yêu cầu kết xuất hoặc hiển thị đối tượng.
Ví dụ:
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)
Dù sao thì nó cũng khá vô dụng, vì tiêu chuẩn không xác định được một số phần chức năng khá phổ biến và quan trọng và thường có các thông số kỹ thuật khá mơ hồ về những thứ mà nó xác định. Chẳng hạn, cho đến gần đây, nó vẫn chưa xác định cách giới hạn số hàng được trả về bởi một truy vấn, vì vậy mỗi cơ sở dữ liệu đều có cú pháp khác nhau (TOP , LIMIT / OFFSET , v.v.).
Những thứ khác mà tiêu chuẩn chỉ định không được hầu hết các nhà cung cấp thực hiện, vì vậy việc sử dụng chúng là khá vô nghĩa. Chúc bạn may mắn khi sử dụng các cột nhận dạng và được tạo theo tiêu chuẩn SQL trên tất cả các nhà cung cấp DB.
Sẽ khá tuyệt nếu có chế độ kết xuất "ưu tiên chính tả chuẩn hơn", được sử dụng CAST thay vì :: , v.v., nhưng nó thực sự không đơn giản để thực hiện vì một số phép biến đổi không thể đảo ngược 1:1, ví dụ:
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));
hoặc:
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;
vì vậy bạn thấy rằng cần phải thực hiện những thay đổi quan trọng đối với cách PostgreSQL đại diện nội bộ và hoạt động với các hàm và biểu thức trước khi những gì bạn muốn có thể thực hiện được.
Rất nhiều nội dung tiêu chuẩn SQL sử dụng cú pháp một lần thú vị mà PostgreSQL chuyển đổi thành các lệnh gọi hàm và truyền trong quá trình phân tích cú pháp, vì vậy nó không phải thêm các tính năng trường hợp đặc biệt mỗi khi SQL committe khác và kéo một số quảng cáo mới cú pháp ra khỏi ... ở đâu đó. Thay đổi điều đó sẽ yêu cầu thêm hàng tấn các loại nút biểu thức mới và tình trạng lộn xộn chung, tất cả đều không đạt được lợi ích thực sự.
