Craig Ringer <craig@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 query was planned for if row
> security was applied. It is also necessary to add a PlanInvalItem for
> the user ID.
TBH I'd just add a user OID field in struct Query and not hack up a bunch
of existing function APIs. It's not much worse than the existing
constraintDeps field.
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 exactly about the *user*, and not something else, would trigger
plan invalidation?
What we do need is a notion that a plan cache entry might only be
valid for a specific calling user ID; but that's a matter for cache
entry lookup not for subsequent invalidation.
regards, tom lane