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

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