La palabra clave IMMUTABLE es nunca agregado automáticamente por pgAdmin o Postgres. Quien haya creado o reemplazado la función hizo eso.
La volatilidad correcta para la función dada es VOLATILE (también el predeterminado), no STABLE - o no tendría sentido usar clock_timestamp() que es VOLATILE en contraste con now() o CURRENT_TIMESTAMP que son STABLE :aquellos devuelven la misma marca de tiempo dentro de la misma transacción. El manual:
clock_timestamp() devuelve la hora actual real y, por lo tanto, su valor cambia incluso dentro de un solo comando SQL.
El manual advierte que la función de volatilidad STABLE ...
es inapropiado para AFTER disparadores que desean consultar las filas modificadas por el comando actual.
.. porque la evaluación repetida de la función de activación puede devolver diferente resultados para la misma fila. Entonces, no STABLE .
Usted pregunta:
¿Tiene alguna idea de por qué la función se devolvió correctamente cinco veces antes de quedarse con el quinto valor cuando se estableció como IMMUTABLE? ?
Wiki de PostgreSQL:
Con 9.2, el planificador usará planes específicos con respecto a los parámetros enviados (la consulta se planificará en ejecución), excepto si la consulta se ejecuta varias veces y el planificador decide que el plan genérico no es mucho más caro que los planes específicos.
Énfasis en negrita mío. No parece tener sentido para un IMMUTABLE función sin parámetros de entrada. Pero la etiqueta falsa es anulada por el VOLATILE función en el cuerpo (vacíos función insertada ):un plan de consulta diferente aún puede tener sentido. Relacionado:
- Rendimiento del procedimiento almacenado de PostgreSQL
Aparte
trunc() es un poco más rápido que floor() y hace lo mismo aquí, ya que se garantizan números positivos:
SELECT (trunc(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int
