On Tue, Apr 06, 2021 at 01:16:16PM -0700, Dan Lynch wrote:
> 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)?
If the function meets the criteria for inlining (see inline_function()),
t
>
>
> > 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
> > qua
On Mon, Apr 05, 2021 at 07:51:46PM -0700, Dan Lynch wrote:
> > > I suppose if the
> > > get_group_ids_of_current_user() function is marked as STABLE, would the
> > > optimizer cache this value for every row in a SELECT that returned
> > > multiple rows?
> >
> > While there was a patch to implement
This is great, thanks! It's great to have somewhere in the source to read
about the optimizer! very cool!
>
> > I suppose if the
> > get_group_ids_of_current_user() function is marked as STABLE, would the
> > optimizer cache this value for every row in a SELECT that returned
> > multiple rows?
>
On Fri, Apr 02, 2021 at 02:24:59PM -0700, Dan Lynch wrote:
> Does anyone know details of, or where to find more information about the
> implications of the optimizer on the quals/checks for the policies being
> functions vs inline?
Roughly, the PostgreSQL optimizer treats LANGUAGE SQL functions li
My goal is to use RLS for everything, including SELECTs, so it's super
important to consider every performance tweak possible. Appreciate any
insights or comments. I'm also hoping to document this better for
application developers who want to use postgres and RLS.
Does anyone know details of, or w
On 4/2/21 10:23 AM, Stephen Frost wrote:
Greetings,
* Joe Conway (m...@joeconway.com) wrote:
On 4/2/21 9:57 AM, Isaac Morland wrote:
>Views already run security definer, allowing them to be used for some of
>the same information-hiding purposes as RLS. But I just found something
>strange: curre
Greetings,
* Joe Conway (m...@joeconway.com) wrote:
> On 4/2/21 9:57 AM, Isaac Morland wrote:
> >Views already run security definer, allowing them to be used for some of
> >the same information-hiding purposes as RLS. But I just found something
> >strange: current_user/_role returns the user's rol
On 4/2/21 9:57 AM, Isaac Morland wrote:
Views already run security definer, allowing them to be used for some of the
same information-hiding purposes as RLS. But I just found something strange:
current_user/_role returns the user's role, not the view owner's role:
postgres=# set role to t1;
S
On Fri, 2 Apr 2021 at 09:44, Chapman Flack wrote:
> On 04/02/21 09:09, Isaac Morland wrote:
> > If we're going to do this we should do the same for triggers as well.
> >
> > ... it's easy to imagine a situation in which a trigger needs to
> > write to another table which should not be accessible
On Fri, 2 Apr 2021 at 09:30, Stephen Frost wrote:
> Greetings,
>
> * Isaac Morland (isaac.morl...@gmail.com) wrote:
> > On Fri, 2 Apr 2021 at 01:44, Dan Lynch wrote:
> > > RLS policies quals/checks are optimized inline, and so I generally
> avoid
> > > writing a separate procedure so the optimiz
On 04/02/21 09:09, Isaac Morland wrote:
> If we're going to do this we should do the same for triggers as well.
>
> ... it's easy to imagine a situation in which a trigger needs to
> write to another table which should not be accessible to the role using the
> table which has the trigger.
Trigger
Greetings,
* Isaac Morland (isaac.morl...@gmail.com) wrote:
> On Fri, 2 Apr 2021 at 01:44, Dan Lynch wrote:
> > RLS policies quals/checks are optimized inline, and so I generally avoid
> > writing a separate procedure so the optimizer can do it's thing.
> >
> > However, if you need a security def
On Fri, 2 Apr 2021 at 01:44, Dan Lynch wrote:
> RLS policies quals/checks are optimized inline, and so I generally avoid
> writing a separate procedure so the optimizer can do it's thing.
>
> However, if you need a security definer to avoid recursive RLS if you're
> doing a more complex query say
14 matches
Mail list logo
