> you seem to be imagining that changes in a query's plan on the basis of changes in collected statistics have something to do with this. They do not.
Sorry, I may not fully understand what you mean. I mean that after my tests, the execution results of this SQL (explain select * from tb_a_date_v1) execution plan are different under different users, which is really related to the parameter proleakproof.
If the 2 below is changed to 'return true' , the execution plan will be indexscan
------------------------------------------------------------------
发件人：Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
发送时间：2022年10月17日(星期一) 11:33
收件人：qiumingcheng <qiumingcheng(at)aliyun(dot)com>
抄 送：Julien Rouhaud <rjuju123(at)gmail(dot)com>; pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
主 题：Re: 回复：A question about leakproof
"qiumingcheng" <qiumingcheng(at)aliyun(dot)com> writes:
> 1. In the test example I gave, the in4eq function's proleakproof=true, but its actual test result is leaking. Does that mean you will adjust it to proleakproof=false later?
int4eq is about as leakproof as a function could possibly be: it does
not leak, it's plain from the code of the function that it does not
leak, and it calls no other code that might accidentally introduce
a leak in future.
I think you do not understand what that property actually means.
Per the CREATE FUNCTION man page:
LEAKPROOF indicates that the function has no side
effects. It reveals no information about its arguments other than by
its return value. For example, a function which throws an error message
for some argument values but not others, or which includes the argument
values in any error message, is not leakproof.
Please note that this definition talks only about the behavior
of the function itself. Re-reading your email, you seem to be
imagining that changes in a query's plan on the basis of changes in
collected statistics have something to do with this. They do not.
regards, tom lane