为什么不能一成不变的UDF在红移的CTE的某些条款中调用？

Question

这个问题可以简化为此，在那里，在一个视图中，任何CTE参照some_immutable_func场所，除了在WHERE，HAVING子句，导致下面的错误::

create or replace function some_immutable_func ()
  returns int
  immutable as $$
    SELECT 1
  $$ language sql;

create view some_view as
WITH some_cte AS (
  SELECT immutable_func()
)
SELECT * FROM some_cte;

FATAL:  Query processing failed due to an internal error.
CONTEXT:  SQL function "immutable_func"
SSL connection has been closed unexpectedly
The connection to the server was lost. Attempting reset: Succeeded.



-- but this is okay
create view some_view as
WITH some_cte AS (
  SELECT * FROM some_table
  WHERE ...some_immutable_func()...
  HAVING ...some_immutable_func()...
)
SELECT * FROM some_cte;
CREATE VIEW

内置的UDF不可改变，如ABS（-3），做工精细。简单地改变UDF是稳定的修复问题，但我期待一个复杂的视图，其中显然有一定UDF的稳定性质减缓下来将近100倍的范围内优化查询性能。理想情况下，我也想尽量减少更改视图的结构，希望做一个简单的替换，而不是全部的清理到WHERE和HAVING子句的UDF的所有引用。

我认为，问题可能是与查询优化器，但我很惊讶有信息那里关于红移/ Postgres的和永恒的神秘/更精细的细节很少。

编辑：我还发现，改变UDF语言蟒蛇似乎很好地工作。然而，它似乎已经在我的具体使用情况相当慢的性能，可能比仅仅使用稳定SQL UDF更糟。

Answer 1

只是想证实，因为这个问题被张贴这已经得到解决。

所提供的例子，现在按预期工作。