Từ khóa IMMUTABLE là không bao giờ được thêm tự động bởi pgAdmin hoặc Postgres. Ai đã tạo hoặc thay thế hàm đã làm điều đó.
Sự biến động chính xác cho hàm đã cho là VOLATILE (cũng là mặc định), không phải STABLE - hoặc sẽ không hợp lý nếu sử dụng clock_timestamp() là VOLATILE trái ngược với now() hoặc CURRENT_TIMESTAMP STABLE :chúng trả về cùng một dấu thời gian trong cùng một giao dịch. Hướng dẫn sử dụng:
clock_timestamp()trả về thời gian hiện tại thực tế và do đó giá trị của nó thay đổi ngay cả trong một lệnh SQL.
Hướng dẫn sử dụng cảnh báo rằng chức năng không ổn định STABLE ...
không thích hợp cho
AFTERkích hoạt muốn truy vấn các hàng được sửa đổi bằng lệnh hiện tại.
.. bởi vì đánh giá lặp lại chức năng kích hoạt có thể trả về khác nhau kết quả cho cùng một hàng. Vì vậy, không phải STABLE .
Bạn hỏi:
Bạn có biết tại sao hàm trả về chính xác năm lần trước khi gắn vào giá trị thứ năm khi được đặt là
IMMUTABLEkhông ?
Wiki của Postgres:
Với 9.2, người lập kế hoạch sẽ sử dụng các kế hoạch cụ thể liên quan đến các tham số được gửi (truy vấn sẽ được lập kế hoạch khi thực thi), ngoại trừ nếu truy vấn được thực thi nhiều lần và người lập kế hoạch quyết định rằng kế hoạch chung không đắt hơn nhiều so với các kế hoạch cụ thể.
Tôi nhấn mạnh đậm. Có vẻ không hợp lý với một IMMUTABLE chức năng không có tham số đầu vào. Nhưng nhãn sai bị ghi đè bởi VOLATILE chức năng trong cơ thể (khoảng trống chức năng nội tuyến ):một kế hoạch truy vấn khác vẫn có thể có ý nghĩa.
- Hiệu suất thủ tục được lưu trữ PostgreSQL
Bên cạnh
trunc() nhanh hơn một chút so với floor() và thực hiện tương tự ở đây, vì số dương được đảm bảo:
SELECT (trunc(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int
