Yes, if I use securtiy_barrierys, it do work, but it still can't use index, I guess it may cause performance problems, right ?
>Also: the fact that a built-in function is not marked leakproof
>doesn't mean that it isn't leakproof. It could just mean that
>we haven't looked at it closely, or that there's too much code
>involved to have much confidence that it would stay leakproof.
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?
2. What basis do you set proleakproof of in4eq function to true? How should I judge whether a function should be marked as proleakproof.Can you give a function that will not leak?
------------------------------------------------------------------
发件人：Tom Lane <tgl@sss.pgh.pa.us>
发送时间：2022年10月17日(星期一) 09:54
收件人：Julien Rouhaud <rjuju123@gmail.com>
抄 送：qiumingcheng <qiumingcheng@aliyun.com>; pgsql-general <pgsql-general@lists.postgresql.org>
主 题：Re: A question about leakproof
Julien Rouhaud <rjuju123@gmail.com> writes:
> On Mon, Oct 17, 2022 at 09:15:20AM +0800, qiumingcheng wrote:
>> After testing, we don't find the difference between functions of
>> proleakproof=true and functions of proleakproof=false (the function is
>> described in pg_proc).
> Have you looked at
> https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.2#Security_barriers_and_Leakproof?
Also: the fact that a built-in function is not marked leakproof
doesn't mean that it isn't leakproof. It could just mean that
we haven't looked at it closely, or that there's too much code
involved to have much confidence that it would stay leakproof.
regards, tom lane