Re: policies with security definer option for allowing inline optimization - Mailing list pgsql-hackers

From Dan Lynch
Subject Re: policies with security definer option for allowing inline optimization
Date
Msg-id CA+_muLF=DGpCOgn2nj7wUJhkh3cieDvuDg5zuHN1z8Xmmf5+kA@mail.gmail.com
Whole thread Raw
In response to Re: policies with security definer option for allowing inline optimization  (Noah Misch <noah@leadboat.com>)
Responses Re: policies with security definer option for allowing inline optimization  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers

> I suppose if the possibility exists that this could happen, perhaps using
> RLS for selects is not quite "production ready"?

I would not draw that conclusion.


This is great to hear! I'm betting a lot on RLS and have been investing a lot into it. 
 
> Or perhaps if the RLS
> qual/check is written well-enough, then maybe the performance hit wouldn't
> be noticed?

Yes.

Amazing to hear. Sounds like the path I'm on is good to go and will only improve over time :)  

Final question: do you think using procedures vs writing inline queries for RLS quals/checks has a big difference in performance (assuming functions are sql)?

Appreciate your info here!

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Stronger safeguard for archive recovery not to miss data
Next
From: Zhihong Yu
Date:
Subject: Re: Parallel Full Hash Join