OK, got it. Thank you very much.
--
发件人：Tom Lane
发送时间：2022年10月18日(星期二) 00:27
收件人：qiumingcheng
抄 送：Laurenz Albe ; Julien Rouhaud
; pgsql-general ;
yuexingzhi
主 题：Re: 回复：回复：回复：回复：A question about leakproof
"qiumingcheng&quo
"qiumingcheng" writes:
> Yes, It's capable of throwing an error(timestamp out of range) , but the
> message "timestamp out of range" is not sensitive information.
Really? Whether that's true at all is a matter of opinion. There's
also the prospect that somebody could determine the value of a
su
be marked as leakproof?
--
发件人：Tom Lane
发送时间：2022年10月17日(星期一) 22:07
收件人：qiumingcheng
抄 送：Laurenz Albe ; Julien Rouhaud
; pgsql-general ;
yuexingzhi
主 题：Re: 回复：回复：回复：A question about leakproof
"qiumingcheng" writes:
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
>
"qiumingcheng" writes:
> 2. What's the reason about the function timestamp_gt_timestampz may cause
> data leakage? Can you explain how it causes data leakage?
It's capable of throwing an error (see
timestamp2timestamptz_opt_overflow). Now, maybe that's unreachable, or
maybe we could rerrange th
in how it causes data leakage?
--
发件人：Laurenz Albe
发送时间：2022年10月17日(星期一) 15:20
收件人：qiumingcheng ; Tom Lane
抄 送：Julien Rouhaud ; pgsql-general
主 题：Re: 回复：回复：A question about leakproof
On Mon, 2022-10-17 at 13:17 +0800, qiumingcheng wrote:
> > you seem to be imagining th
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,
发送时间：2022年10月17日(星期一) 11:33
收件人：qiumingcheng
抄 送：Julien Rouhaud ; pgsql-general
主 题：Re: 回复：A question about leakproof
"qiumingcheng" writes:
> 1. In the test example I gave, the in4eq function's proleakproof=true, but
> its actual test result is leaking. Does that mean y
On Sun, Oct 16, 2022 at 8:33 PM Tom Lane wrote:
> "qiumingcheng" 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 func
"qiumingcheng" 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 fr
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
发送时间：2022年10月17日(星期一) 09:54
收件人：Julien Rouhaud
抄 送：qiumingcheng ; pgsql-general
Julien Rouhaud 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.postgr
Hi,
On Mon, Oct 17, 2022 at 09:15:20AM +0800, qiumingcheng wrote:
> Hello， My questions are as follows：
> Problem description
> 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). Can you
13 matches
Mail list logo
