| 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 20:40:58 |
| Message-ID: | CAFPpqQFQdms2i0Vu9bF3d8THtBzF_WyBMGrNdSO=BO-bQEyV9g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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 | Scott Ribe | 2020-07-24 20:46:06 | bad JIT decision |
| Previous Message | Tom Lane | 2020-07-24 20:15:31 | Re: when is RLS policy applied |