Re: [COMMITTERS] pgsql: Row-Level Security Policies (RLS) - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [COMMITTERS] pgsql: Row-Level Security Policies (RLS)
Date
Msg-id 20150527014206.GF26667@tamriel.snowman.net
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Row-Level Security Policies (RLS)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [COMMITTERS] pgsql: Row-Level Security Policies (RLS)  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
Alvaro,

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> > > What do we need RowSecurityPolicy->policy_id for?  It seems to me that
> > > it is only used to determine whether the policy is the "default deny"
> > > one, so that it can later be removed if a hook adds a different one.
> > > This seems contrived as well as under-documented.  Why isn't a boolean
> > > flag sufficient?
> >
> > Thanks for taking a look!
> >
> > It's also used during relcache updates (see equalPolicy()).
>
> Hmm, but the policy name is unique also, right?  So the policy_id check
> is redundant ...

I don't disagree with that, but surely checking if it's the same OID and
exiting immediately is going to be faster than comparing the policy
names.

Now, looking at the code, I'm actually failing to see a case where we
use the RowSecurityPolicy->policy_name..  Perhaps *that's* what we
should be looking to remove?
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: fsync-pgdata-on-recovery tries to write to more files than previously
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension