From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improving RLS planning |
Date: | 2016-10-26 17:49:58 |
Message-ID: | 7666.1477504198@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Oct 26, 2016 at 1:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Right, so quals from above the SB view would have to not be allowed to
>> drop below the join level (but they could fall *to* the join level,
>> where they'd be applied after the join's own quals). I mentioned that
>> in the part of the message you cut. I don't have a detailed design yet
>> but it seems possible, and I expect it to be a lot simpler than the Rube
>> Goldberg design we've got for SB views now.
> OK; it wasn't clear to me that you had considered that case. I'm not
> convinced that what you end up with is going to be simpler than what
> we have now, but if it is, great.
Well, we already have mechanisms for controlling how far down the join
tree upper quals can fall; outer joins in particular require that. So
I'm thinking that it shouldn't take a lot of additional code for
distribute_qual_to_rels to handle this too. Admittedly, the amount of
boilerplate elsewhere, if it turns out we need a new jointree nodetype
to control this, is not negligible. But I'm thinking it'll be a lot more
straightforward. There's weird warts for security quals all over the
planner right now, and there are still some things about them that I think
work only by accident.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2016-10-26 17:55:50 | Re: Default setting for autovacuum_freeze_max_age |
Previous Message | Merlin Moncure | 2016-10-26 17:43:29 | Re: emergency outage requiring database restart |