回复:回复:回复:A question about leakproof
От | qiumingcheng |
---|---|
Тема | 回复:回复:回复:A question about leakproof |
Дата | |
Msg-id | 195c5d95-8749-4419-a4f4-604cc8c937ec.qiumingcheng@aliyun.com обсуждение исходный текст |
Ответ на | Re: 回复:回复:A question about leakproof (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: 回复:回复:回复:A question about leakproof
Re: 回复:回复:回复:A question about leakproof |
Список | pgsql-general |
> "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."
> in collected statistics have something to do with this. They do not."
1. My understanding of the above paragraph is that for the same view and different users, the proleakproof=false attribute of the function will not lead to inconsistent plans, but my actual test result is that proleakproof=false will lead to inconsistent plans。
2. What's the reason about the function timestamp_gt_timestampz may cause data leakage? Can you explain how it causes data leakage?
------------------------------------------------------------------发件人:Laurenz Albe <laurenz.albe@cybertec.at>发送时间:2022年10月17日(星期一) 15:20收件人:qiumingcheng <qiumingcheng@aliyun.com>; Tom Lane <tgl@sss.pgh.pa.us>抄 送:Julien Rouhaud <rjuju123@gmail.com>; pgsql-general <pgsql-general@lists.postgresql.org>主 题:Re: 回复:回复:A question about leakproofOn Mon, 2022-10-17 at 13:17 +0800, qiumingcheng wrote:
> > 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.
That's the idea behind leakproof: if a function is not leakproof, the optimizer
will not move it "inside" the view definition. Then the function is evaluated only
after the view definition. That may very well lead to a slower execution plan,
because it cannot use certain indexes on the underlying tables.
It is the price you have to pay for good security.
Yours,
Laurenz Albe
В списке pgsql-general по дате отправления: