Re: Improving RLS planning

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: Raw Message | Whole Thread | 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

In response to

Browse pgsql-hackers by date

  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