On Wed, Jun 27, 2012 at 7:21 AM, Florian Pflug <f...@phlo.org> wrote: > On Jun27, 2012, at 07:18 , Kohei KaiGai wrote: >> The problem is the way to implement it. >> If we would have permission checks on planner stage, it cannot handle >> a case when user-id would be switched prior to executor stage, thus >> it needs something remedy to handle the scenario correctly. >> Instead of a unique plan per query, it might be a solution to generate >> multiple plans depending on user-id, and choose a proper one in >> executor stage. >> >> Which type of implementation is what everybody is asking for? > > I think you need to > > a) Determine the user-id at planning time, and insert the matching > RLS clause > > b1) Either re-plan the query if the user-id changes between planning > and execution time, which means making the user-id a part of the > plan-cache key. > > b2) Or decree that for RLS purposes, it's the user-id at planning time, > not execution time, that counts.
Or b3, flag plans that depend on the user ID inside the plan-cache, and just flush all of those (but only those) when the user ID changes. In the common case where RLS is not used, that might ease the sting. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
