Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-25 Thread Robert Haas
On Tue, Jun 24, 2014 at 12:27 PM, Stephen Frost sfr...@snowman.net wrote: I feel like we are getting to the point of simply talking past each other and so I'll try anew, and I'll include my understanding of how the different approaches would address the specific use-case you outlined

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-24 Thread Robert Haas
On Mon, Jun 23, 2014 at 2:29 PM, Stephen Frost sfr...@snowman.net wrote: What are these policies going to depend on? Will they be allowed to overlap? I don't see multi-policy support as being very easily added. We discussed the point about overlap upthread, and I gave specific examples. If

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-24 Thread Alvaro Herrera
Robert Haas wrote: Right, if we were to support multiple policies on a given table then we would have to support adding and removing them individually, as well as specify when they are to be applied- and what if that when overlaps? Do we apply both and only a row which passed them all

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-24 Thread Robert Haas
On Tue, Jun 24, 2014 at 10:30 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Robert Haas wrote: Right, if we were to support multiple policies on a given table then we would have to support adding and removing them individually, as well as specify when they are to be applied- and what

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-24 Thread Stephen Frost
Robert, I feel like we are getting to the point of simply talking past each other and so I'll try anew, and I'll include my understanding of how the different approaches would address the specific use-case you outlined up-thread. Single policy - The current implementation approach

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-24 Thread Dean Rasheed
On 24 June 2014 17:27, Stephen Frost sfr...@snowman.net wrote: Single policy vs Multiple, Overlapping policies vs Multiple, Non-overlapping policies What I was describing upthread was multiple non-overlapping policies. I disagree that this will be more complicated to use. It's a strict

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-24 Thread Dean Rasheed
Thinking about the examples upthread, a separate issue occurs to me --- when defining a RLS qual, I think that there has to be a syntax to specify an alias for the main table, so that correlated subqueries can refer to it. I'm not sure if that's been mentioned in any of the discussions so far, but

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-24 Thread Stephen Frost
Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: Thinking about the examples upthread, a separate issue occurs to me --- when defining a RLS qual, I think that there has to be a syntax to specify an alias for the main table, so that correlated subqueries can refer to it. I'm not sure if

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-24 Thread Craig Ringer
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

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-24 Thread Stephen Frost
Craig, * Craig Ringer (cr...@2ndquadrant.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

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-23 Thread Robert Haas
On Wed, Jun 18, 2014 at 2:18 PM, Stephen Frost sfr...@snowman.net wrote: I'm also of the opinion that this isn't strictly necessary for the initial RLS offering in PG- there's a clear way we could migrate existing users to a multi-policy system from a single-policy system. Sure, to get the

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-23 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: On Wed, Jun 18, 2014 at 2:18 PM, Stephen Frost sfr...@snowman.net wrote: I'm also of the opinion that this isn't strictly necessary for the initial RLS offering in PG- there's a clear way we could migrate existing users to a multi-policy system

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-22 Thread Dean Rasheed
On 17 June 2014 20:19, Robert Haas robertmh...@gmail.com wrote: On Fri, Jun 13, 2014 at 3:11 AM, Dean Rasheed dean.a.rash...@gmail.com wrote: Yeah, I was thinking something like this could work, but I would go further. Suppose you had separate GRANTable privileges for direct access to

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-22 Thread Stephen Frost
Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: On 17 June 2014 20:19, Robert Haas robertmh...@gmail.com wrote: On Fri, Jun 13, 2014 at 3:11 AM, Dean Rasheed dean.a.rash...@gmail.com wrote: Yeah, I was thinking something like this could work, but I would go further. Suppose you

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-20 Thread Stephen Frost
Robert, * Robert Haas (robertmh...@gmail.com) wrote: On Wed, Jun 18, 2014 at 10:40 AM, Stephen Frost sfr...@snowman.net wrote: * Robert Haas (robertmh...@gmail.com) wrote: Technically, there are 4 bits left, and that's what we need for separate privileges. I'd really hate to chew them

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-20 Thread Tom Lane
Stephen Frost sfr...@snowman.net writes: * Robert Haas (robertmh...@gmail.com) wrote: [ counting bits in ACLs ] Wouldn't it be fairly painless to widen AclMode from 32 bits to 64, and thereby double the number of available bits? That code was all written before we required platforms to have an

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-20 Thread Stephen Frost
Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost sfr...@snowman.net writes: * Robert Haas (robertmh...@gmail.com) wrote: [ counting bits in ACLs ] Wouldn't it be fairly painless to widen AclMode from 32 bits to 64, and thereby double the number of available bits? Thanks for

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-18 Thread Robert Haas
On Tue, Jun 17, 2014 at 9:45 PM, Brightwell, Adam adam.brightw...@crunchydatasolutions.com wrote: I absolutely appreciate all of the feedback that has been provided. It has been educational. To your point above, I started putting together a wiki page, as Stephen has spoken to, that is meant

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-18 Thread Robert Haas
On Tue, Jun 17, 2014 at 10:06 PM, Stephen Frost sfr...@snowman.net wrote: * Robert Haas (robertmh...@gmail.com) wrote: On Fri, Jun 13, 2014 at 3:11 AM, Dean Rasheed dean.a.rash...@gmail.com wrote: Yeah, I was thinking something like this could work, but I would go further. Suppose you had

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-18 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: On Tue, Jun 17, 2014 at 10:06 PM, Stephen Frost sfr...@snowman.net wrote: I had taken it to be a single privilege, but you're right, it could be done for each of those.. I really don't think we have the bits for more than one case here though

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-18 Thread Robert Haas
On Tue, Jun 17, 2014 at 10:25 PM, Stephen Frost sfr...@snowman.net wrote: Yeah, if we have to ask an external security module a question for each row, there's little hope of any real optimization. However, I think there will be a significant number of cases where people will want filtering

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-18 Thread Robert Haas
On Wed, Jun 18, 2014 at 10:40 AM, Stephen Frost sfr...@snowman.net wrote: * Robert Haas (robertmh...@gmail.com) wrote: On Tue, Jun 17, 2014 at 10:06 PM, Stephen Frost sfr...@snowman.net wrote: I had taken it to be a single privilege, but you're right, it could be done for each of those.. I

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-18 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: On Tue, Jun 17, 2014 at 10:25 PM, Stephen Frost sfr...@snowman.net wrote: I agree that we want to support that, if we can do so reasonably. What I was trying to get at is simply this- don't we provide that already with the leakproof attribute

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-17 Thread Robert Haas
On Thu, Jun 12, 2014 at 6:33 PM, Gregory Smith gregsmithpg...@gmail.com wrote: I'm kind of surprised to see this turn into a hot button all of the sudden though, because my thought on all that so far has been a giant so what? This is what PostgreSQL does. [...] But let's not act like RLS is a

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-17 Thread Robert Haas
On Fri, Jun 13, 2014 at 3:11 AM, Dean Rasheed dean.a.rash...@gmail.com wrote: Yeah, I was thinking something like this could work, but I would go further. Suppose you had separate GRANTable privileges for direct access to individual tables, bypassing RLS, e.g. GRANT DIRECT

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-17 Thread Robert Haas
On Thu, Jun 12, 2014 at 8:13 PM, Stephen Frost sfr...@snowman.net wrote: I'm in full agreement we should clearly communicate the issues around pg_dump in particular, because they can't necessarily be eliminated altogether without some major work that's going to take a while to finish. And if

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-17 Thread Stephen Frost
Robert, On Tuesday, June 17, 2014, Robert Haas robertmh...@gmail.com wrote: After sending that one (1) email, I was promptly told that I'm very disappointed to hear that the mechanical pieces around making RLS easy for users to use ... is receiving such push-back. The push-back, at that

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-17 Thread Robert Haas
On Mon, Jun 16, 2014 at 1:15 AM, Stephen Frost sfr...@snowman.net wrote: I'm not referring to the proposed implementation particularly; or at least not that aspect of it. I don't think trying to run the view quals as the defining user is likely to be very appealing, because I think it's going

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-17 Thread Brightwell, Adam
Robert, However, I believe that there has been a lack of focus in the development of the patch thus far in a couple of key areas - first in terms of articulating how it is different from and better than a writeable security barrier view, and second on how to manage the security and

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-17 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: On Thu, Jun 12, 2014 at 8:13 PM, Stephen Frost sfr...@snowman.net wrote: This approach was suggested by an existing user testing out this RLS approach, to be fair, but it looks pretty sane to me as a way to address some of these concerns.

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-17 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: On Fri, Jun 13, 2014 at 3:11 AM, Dean Rasheed dean.a.rash...@gmail.com wrote: Yeah, I was thinking something like this could work, but I would go further. Suppose you had separate GRANTable privileges for direct access to individual tables,

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-17 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: On Mon, Jun 16, 2014 at 1:15 AM, Stephen Frost sfr...@snowman.net wrote: I understand that there are performance implications. As mentioned to Tom, realistically, there's zero way to optimized at least some of these use-cases because they

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-16 Thread Stephen Frost
Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: On 13 June 2014 01:13, Stephen Frost sfr...@snowman.net wrote: This approach was suggested by an existing user testing out this RLS approach, to be fair, but it looks pretty sane to me as a way to address some of these concerns.

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-16 Thread Kevin Grittner
Stephen Frost sfr...@snowman.net wrote: Kevin Grittner (kgri...@ymail.com) wrote: The proposed approach would leave the validity of any dump which was not run as a superuser in doubt.  The last thing we need, in terms of improving security, is another thing you can't do without connecting as

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-16 Thread Stephen Frost
* Kevin Grittner (kgri...@ymail.com) wrote: Stephen Frost sfr...@snowman.net wrote: Any dump not run by a superuser is already in doubt, imv.  That is a problem we already have which really needs to be addressed, but I view that as an independent issue. I'm not seeing that.  If the user

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-15 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: Adam Brightwell adam.brightw...@crunchydatasolutions.com writes: Through this effort, we have concluded that for RLS the case of invalidating a plan is only necessary when switching between a superuser and a non-superuser. Obviously, re-planning on

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-15 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: Craig Ringer cr...@2ndquadrant.com writes: I agree, and now that the urgency of trying to deliver this for 9.4 is over it's worth seeing if we can just run as table owner. Failing that, we could take the approach a certain other RDBMS does and make

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-15 Thread Stephen Frost
Robert, * Robert Haas (robertmh...@gmail.com) wrote: On Wed, Jun 11, 2014 at 8:59 PM, Stephen Frost sfr...@snowman.net wrote: In this case the user-defined code needs to return a boolean. We don't currently do anything to prevent it from having side-effects, no, but the same is true with

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-15 Thread Stephen Frost
Kevin, * Kevin Grittner (kgri...@ymail.com) wrote: Robert Haas robertmh...@gmail.com wrote: Even aside from security exposures, how does a non-superuser who runs pg_dump know whether they've got a complete backup or a filtered dump that's missing some rows? This seems to me to be a

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-13 Thread Dean Rasheed
On 13 June 2014 01:13, Stephen Frost sfr...@snowman.net wrote: Greg, all, I will reply to the emails in detail when I get a chance but am out of town at a funeral, so it'll likely be delayed. I did want to echo my agreement for the most part with Greg and in particular... On Thursday, June

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-12 Thread Kevin Grittner
Robert Haas robertmh...@gmail.com wrote: Even aside from security exposures, how does a non-superuser who runs pg_dump know whether they've got a complete backup or a filtered dump that's missing some rows? This seems to me to be a killer objection to the feature as proposed, and points out a

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-12 Thread Gregory Smith
On 6/11/14, 10:26 AM, Robert Haas wrote: Now, as soon as we introduce the concept that selecting from a table might not really mean read from the table but read from the table after applying this owner-specified qual, we're opening up a whole new set of attack surfaces. Every pg_dump is an

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-12 Thread Stephen Frost
Greg, all, I will reply to the emails in detail when I get a chance but am out of town at a funeral, so it'll likely be delayed. I did want to echo my agreement for the most part with Greg and in particular... On Thursday, June 12, 2014, Gregory Smith gregsmithpg...@gmail.com wrote: On

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-11 Thread Robert Haas
On Tue, Jun 10, 2014 at 7:18 PM, Craig Ringer cr...@2ndquadrant.com wrote: On 06/11/2014 02:19 AM, Tom Lane wrote: Hm ... I'm not following why we'd need a special case for superusers and not anyone else? Seems like any useful RLS scheme is going to require more privilege levels than just

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-11 Thread Stephen Frost
* Craig Ringer (cr...@2ndquadrant.com) wrote: On 06/11/2014 02:19 AM, Tom Lane wrote: Hm ... I'm not following why we'd need a special case for superusers and not anyone else? Seems like any useful RLS scheme is going to require more privilege levels than just superuser and not-superuser.

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-11 Thread Stephen Frost
* Craig Ringer (cr...@2ndquadrant.com) wrote: On 06/11/2014 07:24 AM, Tom Lane wrote: Is the point of that that the table owner might have put trojan-horse functions into the RLS qual? If so, why are we only concerned about defending the superuser and not other users? Seems like the right

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-11 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: I'm really concerned about the security implications of this patch. I think we're setting ourselves up for a whole lot of hurt for somewhat unclear gain. I'm certainly of a different opinion and, for the most part, I feel that if there are security

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-11 Thread Tom Lane
Stephen Frost sfr...@snowman.net writes: * Robert Haas (robertmh...@gmail.com) wrote: I'm really concerned about the security implications of this patch. I think we're setting ourselves up for a whole lot of hurt for somewhat unclear gain. I'm certainly of a different opinion and, for the

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-11 Thread Robert Haas
On Wed, Jun 11, 2014 at 12:23 PM, Stephen Frost sfr...@snowman.net wrote: In my view, commit 842faa714c0454d67e523f5a0b6df6500e9bc1a5 basically *is* row-level security: instead of applying a row-level security policy to a table, just create a security-barrier view over the table and grant

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-11 Thread Stephen Frost
Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost sfr...@snowman.net writes: * Robert Haas (robertmh...@gmail.com) wrote: I'm really concerned about the security implications of this patch. I think we're setting ourselves up for a whole lot of hurt for somewhat unclear gain.

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-11 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote: On Wed, Jun 11, 2014 at 12:23 PM, Stephen Frost sfr...@snowman.net wrote: This argument could have been made for column-level privileges also, no? Not really. First of all, we didn't have security_barrier views at that time, let alone security

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-11 Thread Robert Haas
On Wed, Jun 11, 2014 at 8:59 PM, Stephen Frost sfr...@snowman.net wrote: Row-level security is not a chance for the system to deny access; it's a chance for user-defined code to take control and perform arbitrary operations. So the scope of what we're contemplating for row-level security is

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-10 Thread Adam Brightwell
Hi all, This is my first post to the mailing list and I am looking forward to working with everyone in the community. With that said... I'll take a look at changing the cache key to include user ID and ripping out the plan invalidation logic from the current patch tomorrow but I seriously

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-10 Thread Tom Lane
Adam Brightwell adam.brightw...@crunchydatasolutions.com writes: Through this effort, we have concluded that for RLS the case of invalidating a plan is only necessary when switching between a superuser and a non-superuser. Obviously, re-planning on every role change would be too costly, but

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-10 Thread Brightwell, Adam
Hey Tom, Hm ... I'm not following why we'd need a special case for superusers and not anyone else? Seems like any useful RLS scheme is going to require more privilege levels than just superuser and not-superuser. As it stands right now, superuser is the only case where RLS policies should

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-10 Thread Craig Ringer
On 06/11/2014 02:19 AM, Tom Lane wrote: Hm ... I'm not following why we'd need a special case for superusers and not anyone else? Seems like any useful RLS scheme is going to require more privilege levels than just superuser and not-superuser. What it really needs is to invalidate plans when

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-10 Thread Tom Lane
Craig Ringer cr...@2ndquadrant.com writes: On 06/11/2014 02:19 AM, Tom Lane wrote: Could we put the if superuser then ok test into the RLS condition test and thereby not need more than one plan at all? Only if we put it in another level of security barrier subquery, because otherwise the

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-10 Thread Craig Ringer
On 06/11/2014 07:24 AM, Tom Lane wrote: Is the point of that that the table owner might have put trojan-horse functions into the RLS qual? If so, why are we only concerned about defending the superuser and not other users? Seems like the right fix would be to insist that functions in the RLS

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-06-10 Thread Tom Lane
Craig Ringer cr...@2ndquadrant.com writes: On 06/11/2014 07:24 AM, Tom Lane wrote: Is the point of that that the table owner might have put trojan-horse functions into the RLS qual? If so, why are we only concerned about defending the superuser and not other users? Seems like the right fix

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-04-24 Thread Craig Ringer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/15/2014 10:06 AM, Stephen Frost wrote: I've uploaded the latest patch, rebased against master, with my changes to here: http://snowman.net/~sfrost/rls_ringerc_sf.patch.gz as I don't believe it'd clear the mailing list (it's 29k). Does this

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-04-24 Thread Stephen Frost
* Craig Ringer (cr...@2ndquadrant.com) wrote: On 04/15/2014 10:06 AM, Stephen Frost wrote: I've uploaded the latest patch, rebased against master, with my changes to here: http://snowman.net/~sfrost/rls_ringerc_sf.patch.gz as I don't believe it'd clear the mailing list (it's 29k). Does

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-04-14 Thread Stephen Frost
Craig, Tom, all, I've been through the RLS code over the past couple of days which I pulled from Craig's repo and have a bunch of minor updates. In general, the patch seems pretty reasonable- except for the issues discussed below. Quite a bit of this patch is tied up in plan invalidation and

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-04-14 Thread Tom Lane
Stephen Frost sfr...@snowman.net writes: I've uploaded the latest patch, rebased against master, with my changes to here: http://snowman.net/~sfrost/rls_ringerc_sf.patch.gz as I don't believe it'd clear the mailing list (it's 29k). Please actually post it, for the archives' sake. 29k is far

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-04-14 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: Stephen Frost sfr...@snowman.net writes: I've uploaded the latest patch, rebased against master, with my changes to here: http://snowman.net/~sfrost/rls_ringerc_sf.patch.gz as I don't believe it'd clear the mailing list (it's 29k). Please actually

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-03-07 Thread Tom Lane
Craig Ringer cr...@2ndquadrant.com writes: On 03/06/2014 02:58 AM, Tom Lane wrote: The PlanInvalItem could perfectly well be generated by the planner, no, if it has the user OID? But I'm not real sure why you need it. I don't see the reason for an invalidation triggered by user ID. What

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-03-06 Thread Craig Ringer
On 03/06/2014 02:58 AM, Tom Lane wrote: Craig Ringer cr...@hobby.2ndquadrant.com writes: One of the remaining issues with row security is how to pass plan invalidation information generated in the rewriter back into the planner. With row security, it's necessary to set a field in

Re: [HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-03-05 Thread Tom Lane
Craig Ringer cr...@hobby.2ndquadrant.com writes: One of the remaining issues with row security is how to pass plan invalidation information generated in the rewriter back into the planner. With row security, it's necessary to set a field in PlannerGlobal, tracking the user ID of the user the

[HACKERS] API change advice: Passing plan invalidation info from the rewriter into the planner?

2014-03-04 Thread Craig Ringer
Hi all One of the remaining issues with row security is how to pass plan invalidation information generated in the rewriter back into the planner. With row security, it's necessary to set a field in PlannerGlobal, tracking the user ID of the user the query was planned for if row security was