我们编写了一个定义为
的函数get_timestamp()
CREATE OR REPLACE FUNCTION get_timestamp()
RETURNS integer AS
$$
SELECT (FLOOR(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int;
$$
LANGUAGE SQL;
这在INSERT和UPDATE上用于输入或编辑数据库记录中已创建和已修改字段中的值。但是,我们发现连续添加或更新记录时它返回的值相同。
在检查pgAdmin III中的函数时,我们注意到在运行SQL来构建函数时,在LANGUAGE SQL语句之后注入了关键字IMMUTABLE。 documentation表示默认值是VOLATILE(如果没有出现,VOLATILE是默认假设),所以我不确定注入IMMUTABLE的原因,但是,将其更改为STABLE已解决了重复值的问题。
注意:如接受的答案中所述,IMMUTABLE永远不会被pgAdmin或Postgres添加到函数中,并且必须在开发期间添加。
我猜测正在发生的事情是这个函数正在被评估并且结果被缓存用于优化,因为它被标记为IMMUTABLE指示Postgres引擎在给定相同(空)参数列表的情况下返回值不应该改变。但是,当在触发器中未使用时,直接在INSERT语句中使用时,该函数将返回一个不同的值五次,然后再返回相同的值。这是由于某些优化算法会出现类似"如果IMMUTABLE函数在会话中使用的次数超过5次,则将结果缓存以供将来调用"?
有关如何在Postgres函数中使用这些关键字的任何说明将不胜感激。对于我们来说STABLE是正确的选择,因为我们在触发器中使用了这个函数,或者还有更多要考虑的东西,例如文档说:
(对于希望查询行的AFTER触发器不合适 由当前命令修改。)
但我并不清楚原因。
答案 0 :(得分:7)
pgAdmin或Postgres自动添加关键字IMMUTABLE
从不。谁曾创建或替换过这个功能。
给定功能的正确function volatility(阅读手册)设置为 VOLATILE
,而不是STABLE
- 或者使用它没有意义VOLATILE
STABLE
而不是clock_timestamp()
或now()
,其定义为clock_timestamp()
:那些在同一事务中返回相同的时间戳,{{3} }:
STABLE
返回实际的当前时间,因此返回它 即使在单个SQL命令中,值也会发生变化。
CURRENT_TIMESTAMP
函数波动率AFTER
...
不适合希望查询已修改行的
STABLE
个触发器 通过当前命令。
..因为重复评估同一行的触发器功能可以返回不同的结果。所以,不是IMMUTABLE
。我认为甚至不需要警告,因为它很明显。
你问:
您是否知道该函数为何正确返回5 设置为
IMMUTABLE
时,在坚持第五个值之前的时间?
对于9.2,规划人员将使用有关的具体计划 发送的参数(查询将在执行时计划),除非是 查询多次执行,计划程序决定 通用计划并不比具体计划昂贵得多。
大胆强调我的。对VOLATILE
函数似乎没有意义(也不会造成伤害),但也许使用floor()
函数仍会触发初始重新规划。 (最后一点只是我的推测。)
这里有更多解释:
Postgres Wiki略快于SELECT (trunc(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int
并在此处执行相同操作,因为保证了正数:
{{1}}