回复：[Internet]Re: Re: 回复：Re: [PATCH] Pr event replacement of a function if it's used in an index expression and is not IMMUTABLE

Dear David,

Thank you very much for your feedback and clarification.

We now realize that the current immutability mechanism in PostgreSQL has been established for a long time, and changing it at this point would not only be difficult but also risk breaking backward compatibility.

We appreciate your insights regarding the implications and trade-offs. We are now exploring alternative ways to address this issue within our specific use case, possibly via external tooling or extension-level enforcement.

If we find a more viable solution that balances compatibility and safety, we’d be happy to discuss it further with the community.

Thanks again for your time and guidance.

Best regards,
xiaojiluo(tencent security yunding lab), sundayjiang(tencent security yunding Lab)

David G. Johnston<david(dot)g(dot)johnston(at)gmail(dot)com&gt;&nbsp;在 2025年7月10日 周四 21:14 写道：

On Wednesday, July 9, 2025, sundayjiang(蒋浩天) <sundayjiang(at)tencent(dot)com&gt; wrote:

&nbsp; &nbsp; - When creating a function, if it is declared as IMMUTABLE but directly calls a non-IMMUTABLE function, the creation should be rejected.

This patch is not going to be accepted in core.&nbsp; In short, your desire to have the server enforce this is too late.&nbsp; We don’t get to change our policy.

The alter function + index is at least reasonable since it affects a dump-restore scenario; but was deemed too expensive for the benefit.&nbsp; Arguably we should just get rid of the immutability check for create index since our enforcement of it has so many holes.

David J.