| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | qiumingcheng <qiumingcheng(at)aliyun(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: 回复：回复：A question about leakproof |
| Date: | 2022-10-17 07:19:57 |
| Message-ID: | 9e253a3226436819f0aaf59fb82137477d9f5a78.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | qiumingcheng | 2022-10-17 08:24:34 | 回复：回复：回复：A question about leakproof |
| Previous Message | Rama Krishnan | 2022-10-17 06:14:32 | About foreign data wrapper |