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 doubt I'll be able to get all of that done in the next > day or two. If anyone else is able to help out, it'd certainly be > appreciated; I really think that's the main hurdle to address at this > point with this patch- without the plan invalidation complexity, the > the patch is really just building out the catalog, the SQL-level > statements for managing it, and the bit of code required to add the > conditional to statements involving RLS-enabled tables. > I have been collaborating with Stephen on addressing this particular item with RLS. As a basis, I have been working with Craig's 'rls-9.4-upd-sb-views' branch rebased against master around 9.4beta1. 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 this approach should help minimize that cost. As well, there were not any cases outside of this one that were immediately apparent with respect to RLS that would require re-planning on a per userid basis. I have tested this approach with the following patch. https://github.com/abrightwell/postgres/commit/4c959e63f7a89b24ebbd46575a31a629d24efa75 Does this sound like a sane approach? Thoughts? Recommendations? Thanks, Adam
