Kata kuncinya IMMUTABLE adalah tidak pernah ditambahkan secara otomatis oleh pgAdmin atau Postgres. Siapa pun yang membuat atau mengganti fungsi tersebut yang melakukannya.
volatilitas yang benar untuk fungsi yang diberikan adalah VOLATILE (juga default), bukan STABLE - atau tidak masuk akal untuk menggunakan clock_timestamp() yaitu VOLATILE berbeda dengan now() atau CURRENT_TIMESTAMP yang STABLE :mereka mengembalikan stempel waktu yang sama dalam transaksi yang sama. Panduan:
clock_timestamp()mengembalikan waktu aktual saat ini, dan oleh karena itu nilainya berubah bahkan dalam satu perintah SQL.
Manual memperingatkan bahwa volatilitas fungsi STABLE ...
tidak pantas untuk
AFTERpemicu yang ingin meminta baris yang dimodifikasi oleh perintah saat ini.
.. karena evaluasi berulang dari fungsi pemicu dapat mengembalikan berbeda hasil untuk baris yang sama. Jadi, bukan STABLE .
Anda bertanya:
Apakah Anda memiliki gagasan mengapa fungsi tersebut dikembalikan dengan benar lima kali sebelum tetap pada nilai kelima ketika ditetapkan sebagai
IMMUTABLE?
Wiki Postgres:
Dengan 9.2, perencana akan menggunakan rencana khusus mengenai parameter yang dikirim (kueri akan direncanakan saat dieksekusi), kecuali jika kueri dieksekusi beberapa kali dan perencana memutuskan bahwa paket umum tidak terlalu mahal daripada paket khusus.
Penekanan saya yang berani. Tampaknya tidak masuk akal untuk IMMUTABLE fungsi tanpa parameter masukan. Tapi label palsu ditimpa oleh VOLATILE fungsi dalam tubuh (membatalkan fungsi sebaris ):rencana kueri yang berbeda masih bisa masuk akal.Terkait:
- Kinerja Prosedur Tersimpan PostgreSQL
Selain
trunc() sedikit lebih cepat dari floor() dan melakukan hal yang sama di sini, karena angka positif dijamin:
SELECT (trunc(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int
