Re: 回复:回复:回复:A question about leakproof

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>, yuexingzhi <yuexingzhi(at)hotmail(dot)com>
Subject: Re: 回复:回复:回复:A question about leakproof
Date: 2022-10-17 14:07:33
Message-ID: 7ea51194f227584cc85a428bc4ef5d39ed36f5b8.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, 2022-10-17 at 16:24 +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."
>
> 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.

The above says "on the basis of changes in collected statistics". The different execution
you see is not because the statistics are different, but because the permissions of the
users are different.

> 2. What's the reason about the function timestamp_gt_timestampz  may  cause data leakage?
> Can you explain how it causes data leakage?

I don't know the reason in this case. You could look at the source code, perhaps it is
possible to cause error messages that can give you some clue as to the value that you
compare with. But perhaps, as Tome said, it is just that nobody scrutinized the function
hard enough to exclude that something like that can happen.

Yours,
Laurenz Albe

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Rob Sargent 2022-10-17 14:14:20 Re: could not find shared library for Python
Previous Message Tom Lane 2022-10-17 14:07:18 Re: 回复:回复:回复:A question about leakproof