| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Yeb Havinga <yeb(dot)havinga(at)portavita(dot)nl> |
| Subject: | Re: API change advice: Passing plan invalidation info from the rewriter into the planner? |
| Date: | 2014-06-25 01:33:48 |
| Message-ID: | 20140625013348.GE16098@tamriel.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Craig,
* Craig Ringer (craig(at)2ndquadrant(dot)com) wrote:
> On 06/24/2014 10:30 PM, Alvaro Herrera wrote:
> > I haven't been following this thread, but this bit caught my attention.
> > I'm not sure I agree that OR is always the right policy either.
> > There is a case for a policy that says "forbid these rows to these guys,
> > even if they have read permissions from elsewhere".
>
> That's generally considered a "DENY" policy, a concept borrowed from ACLs.
Right.
> > If OR is the only
> > way to mix multiple policies there might not be a way to implement this.
>
> I think that's a "later" myself, but we shouldn't design ourselves into
> a corner where we can't support deny rules either.
Agreed, but I don't want to get so wrapped up in all of this that we end
up with a set of requirements so long that we'll never be able to
accomplish them all in a single release...
Thanks!
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2014-06-25 01:40:15 | Re: Allowing NOT IN to use ANTI joins |
| Previous Message | Craig Ringer | 2014-06-25 01:31:36 | Re: API change advice: Passing plan invalidation info from the rewriter into the planner? |