Nøgleordet IMMUTABLE er aldrig tilføjet automatisk af pgAdmin eller Postgres. Den, der har oprettet eller erstattet funktionen, gjorde det.
Den korrekte volatilitet for den givne funktion er VOLATILE (også standard), ikke STABLE - ellers ville det ikke give mening at bruge clock_timestamp() som er VOLATILE i modsætning til now() eller CURRENT_TIMESTAMP som er STABLE :de returnerer det samme tidsstempel inden for samme transaktion. Manualen:
clock_timestamp() returnerer den aktuelle aktuelle tid, og derfor ændres dens værdi selv inden for en enkelt SQL-kommando.
Manualen advarer om, at funktionsvolatilitet STABLE ...
er upassende for AFTER triggere, der ønsker at forespørge på rækker, der er ændret af den aktuelle kommando.
.. fordi gentagen evaluering af triggerfunktionen kan returnere anderledes resultater for samme række. Altså ikke STABLE .
Du spørger:
Har du en idé om, hvorfor funktionen returnerede korrekt fem gange, før den blev fastholdt på den femte værdi, når den blev sat som IMMUTABLE ?
Postgres Wiki:
Med 9.2 vil planlæggeren bruge specifikke planer vedrørende de sendte parametre (forespørgslen vil blive planlagt ved udførelse), undtagen hvis forespørgslen udføres flere gange og planlæggeren beslutter, at den generiske plan ikke er for meget dyrere end de specifikke planer.
Fed understregning min. Det lader ikke til at give mening for en IMMUTABLE funktion uden inputparametre. Men den falske etiket tilsidesættes af VOLATILE funktion i kroppen (tomrum funktion inlining ):en anden forespørgselsplan kan stadig give mening.Relateret:
- PostgreSQL Stored Procedure Performance
Til side
trunc() er lidt hurtigere end floor() og gør det samme her, da positive tal er garanteret:
SELECT (trunc(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int