Het sleutelwoord IMMUTABLE is nooit automatisch toegevoegd door pgAdmin of Postgres. Degene die de functie heeft gemaakt of vervangen, heeft dat gedaan.
De juiste volatiliteit voor de gegeven functie is VOLATILE (ook de standaard), niet STABLE - of het zou geen zin hebben om clock_timestamp() . te gebruiken dat is VOLATILE in tegenstelling tot now() of CURRENT_TIMESTAMP die STABLE . zijn :die retourneren hetzelfde tijdstempel binnen dezelfde transactie. De handleiding:
clock_timestamp()geeft de werkelijke huidige tijd terug, en daarom verandert de waarde ervan zelfs binnen een enkele SQL-opdracht.
De handleiding waarschuwt voor de functie volatiliteit STABLE ...
is ongepast voor
AFTERtriggers die rijen willen opvragen die zijn gewijzigd door de huidige opdracht.
.. omdat herhaalde evaluatie van de triggerfunctie anders kan opleveren resultaten voor dezelfde rij. Dus niet STABLE .
Je vraagt:
Heb je een idee waarom de functie vijf keer correct is geretourneerd voordat je de vijfde waarde vasthoudt wanneer deze is ingesteld als
IMMUTABLE?
De Postgres-wiki:
Met 9.2 zal de planner specifieke plannen gebruiken met betrekking tot de verzonden parameters (de query wordt gepland bij uitvoering), behalve als de query meerdere keren wordt uitgevoerd en de planner besluit dat het generieke plan niet te veel duurder is dan de specifieke plannen.
Vetgedrukte nadruk van mij. Lijkt niet logisch voor een IMMUTABLE functie zonder invoerparameters. Maar het valse label wordt overschreven door de VOLATILE functie in het lichaam (leegtes function inlining ):een ander zoekplan kan nog steeds zinvol zijn. Gerelateerd:
- Prestaties van opgeslagen PostgreSQL-procedure
Terzijde
trunc() is iets sneller dan floor() en doet hier hetzelfde, aangezien positieve getallen gegarandeerd zijn:
SELECT (trunc(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int