Nyckelordet IMMUTABLE är aldrig läggs till automatiskt av pgAdmin eller Postgres. Den som skapade eller ersatte funktionen gjorde det.
Rätt volatilitet för den givna funktionen är VOLATILE (också standard), inte STABLE - annars skulle det inte vara meningsfullt att använda clock_timestamp() som är VOLATILE i motsats till now() eller CURRENT_TIMESTAMP som är STABLE :de returnerar samma tidsstämpel inom samma transaktion. Manualen:
clock_timestamp()returnerar den aktuella tiden, och därför ändras dess värde även inom ett enda SQL-kommando.
Handboken varnar för att funktionsvolatiliteten STABLE ...
är olämpligt för
AFTERtriggers som vill fråga rader modifierade av det aktuella kommandot.
.. eftersom upprepad utvärdering av triggerfunktionen kan returnera annorlunda resultat för samma rad. Alltså inte STABLE .
Du frågar:
Har du en idé om varför funktionen returnerade korrekt fem gånger innan den fastnade på det femte värdet när den ställdes in som
IMMUTABLE?
Postgres Wiki:
Med 9.2 kommer planeraren att använda specifika planer för de parametrar som skickas (frågan kommer att planeras vid körning), förutom om frågan körs flera gånger och planeraren bestämmer att den allmänna planen inte är för mycket dyrare än de specifika planerna.
Djärv betoning min. Verkar inte vara vettigt för en IMMUTABLE funktion utan ingångsparametrar. Men den falska etiketten åsidosätts av VOLATILE funktion i kroppen (tomrum funktion inlining ):en annan frågeplan kan fortfarande vara meningsfull.Relaterat:
- Prestanda för PostgreSQL lagrad procedur
Åsido
trunc() är något snabbare än floor() och gör samma sak här, eftersom positiva tal garanteras:
SELECT (trunc(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int