Tại sao các hàm PL / pgSQL có thể có tác dụng phụ, trong khi các hàm SQL thì không?

Bạn đã tự tô đậm câu quan trọng trong sách hướng dẫn:

Toàn bộ phần nội dung của một hàm SQL được phân tích cú pháp trước khi bất kỳ hàm nào trong số đó được thực thi.

Cũng đọc về Giai đoạn phân tích cú pháp trong sách hướng dẫn.

Nó bao gồm hai phần chính: trình phân tích cú pháp và quá trình chuyển đổi . Trích dẫn hướng dẫn sử dụng:

quá trình biến đổi lấy lại cây do trình phân tích cú pháp asinput và giải thích ngữ nghĩa cần thiết để hiểu các bảng, hàm và toán tử nào được tham chiếu bởi truy vấn.

Nếu một hàm SQL chứa các lệnh sau:

CREATE TABLE foo (...);
INSERT INTO foo VALUES(...);

Cả hai câu lệnh được lập kế hoạch hầu như cùng một lúc (dựa trên cùng một ảnh chụp nhanh các danh mục hệ thống). Do đó, INSERT không thể thấy bảng "foo" có lẽ đã được tạo bằng CREATE trước đó yêu cầu. Điều đó tạo ra một trong những sự cố sau :

1. Nếu không có khác bảng có tên "foo" trong search_patch của bạn (chưa), Postgres phàn nàn khi cố gắng tạo chức năng:

   ERROR:  relation "foo" does not exist
   

2. Nếu một bảng khác có tên "foo" đã tồn tại trong search_patch của bạn (và bạn không sử dụng các tên cột xung đột), Postgres sẽ lập kế hoạch INSERT dựa trên bảng có sẵn đó. Thông thường, điều đó dẫn đến lỗi tại thời điểm thực thi , nếu bất kỳ giá trị nào gây ra xung đột trong bảng (sai!). Hoặc, với một số vận rủi, nó thậm chí có thể ghi vào bảng đó mà không có thông báo lỗi! Lỗi rất lén lút.

Điều đó không thể xảy ra với PL / pgSQL , bởi vì nó xử lý các lệnh SQL giống như các câu lệnh đã chuẩn bị, được lập kế hoạch và thực thi tuần tự . Vì vậy, mỗi câu lệnh có thể thấy các đối tượng được tạo trong các câu lệnh trước đó.

Do đó, các câu lệnh không bao giờ được truy cập thậm chí không bao giờ được lập kế hoạch - không giống như các hàm SQL. Và kế hoạch thực thi cho các câu lệnh có thể được lưu vào bộ đệm trong cùng một phiên - cũng không giống như các hàm SQL. Đọc chi tiết về bộ đệm kế hoạch trong các hàm PL / pgSQL trong sách hướng dẫn tại đây.
Mỗi cách tiếp cận đều có lợi thế đối với một số trường hợp sử dụng. Đọc thêm:

• Sự khác biệt giữa ngôn ngữ sql và ngôn ngữ plpgsql trong các hàm PostgreSQL