Ключовата дума IMMUTABLE еникога добавя автоматично от pgAdmin или Postgres. Който и да е създал или заменил функцията, е направил това.
Правилната волатилност за дадената функция е VOLATILE (също по подразбиране), а не STABLE - или няма да има смисъл да използвате clock_timestamp() което е VOLATILE за разлика от now() или CURRENT_TIMESTAMP които са STABLE :те връщат едно и също времеви печат в рамките на една и съща транзакция. Ръководството:
clock_timestamp()връща действителното текущо време и следователно стойността му се променя дори в рамките на една SQL команда.
Ръководството предупреждава, че волатилността на функцията STABLE ...
е неподходящ за
AFTERтригери, които искат да заявят редове, модифицирани от текущата команда.
.. защото многократното оценяване на функцията за задействане може да върне различно резултати за същия ред. Така че не STABLE .
Вие питате:
Имате ли идея защо функцията се връща правилно пет пъти, преди да залепи петата стойност, когато е зададена като
IMMUTABLE?
The Postgres Wiki:
С 9.2 плановникът ще използва специфични планове по отношение на изпратените параметри (заявката ще бъде планирана при изпълнение), освен ако заявката се изпълни няколко пъти и планиращият решава, че общият план не е много по-скъп от конкретните планове.
Удебелен акцент мой. Изглежда, че няма смисъл за IMMUTABLE функция без входни параметри. Но фалшивият етикет е заменен от VOLATILE функция в тялото (загубва вградената функция ):различен план за заявка все още може да има смисъл. Свързано:
- Ефективност на PostgreSQL съхранената процедура
Настрана
trunc() е малко по-бърз от floor() и прави същото тук, тъй като положителните числа са гарантирани:
SELECT (trunc(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int
