From: | Ted Toth <txtoth(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: when is RLS policy applied |
Date: | 2020-07-24 21:12:03 |
Message-ID: | CAFPpqQFSfCjmx3TYjjDTECUgpeDkuPFQQO8Qe+s9TMdOjzV3gg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I've looked for information on leakproofness of operators but haven't found
anything can you direct me to a source of this information?
On Fri, Jul 24, 2020 at 3:40 PM Ted Toth <txtoth(at)gmail(dot)com> wrote:
>
> On Fri, Jul 24, 2020 at 3:15 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Ted Toth <txtoth(at)gmail(dot)com> writes:
>> > I'm trying to understand when RLS select policy is applied so I created
>> the
>> > follow to test but I don't understand why the query filter order is
>> > different for the 2 queries can anyone explain?
>>
>> The core reason why not is that the ~~ operator isn't considered
>> leakproof. Plain text equality is leakproof, so it's safe to evaluate
>> ahead of the RLS filter --- and we'd rather do so because the plpgsql
>> function is assumed to be much more expensive than a built-in operator.
>>
>> (~~ isn't leakproof because it can throw errors that expose information
>> about the pattern argument.)
>>
>> regards, tom lane
>>
>
> Thanks for the explanation.
>
> Ted
>
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2020-07-24 21:15:03 | Re: when is RLS policy applied |
Previous Message | Tom Lane | 2020-07-24 21:09:33 | Re: Row estimates for empty tables |