"qiumingcheng" <qiumingcheng@aliyun.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.
You omitted including the part about when the system even has to care about leakproof:
"This affects how the system executes queries against views created with the security_barrier option or tables with row level security enabled."
A non-leakproof function must not be called with inputs that the current user is not allowed to see. Allowed being the operative word, if they could see the value if not for other non-security-related conditions in the query it is acceptable to call the function with those inputs even if the end result is simply going to be thrown away later (while inefficient, this is why function cost is tunable). None of your examples prohibit any row from being processed by any function and so your spy function may see any and all rows present in the table.
A leakproof function is allowed to process data that the current user is not allowed to see - because if the input row ends up being filtered out the values of the input arguments will never be viewable by the user. They will neither be in the query output, nor able to be read or inferred by some kind of side-effect. Your spy function, which is not leakproof, should never see such prohibited rows - which you seem to have confirmed. The planner indeed must ensure other security-related filters are applied first.