On Fri, 2010-07-09 at 13:21 -0400, Tom Lane wrote: > > Agreed that permission checks should logically be applied at > execution > > time. I am proposing a performance optimisation, not a change in > > behaviour. > > Except that it *is* a change in behavior: the first check will occur > too > soon.
Sooner matters why? We already have a lock on the table at plan time so there cannot be a concurrent GRANT against a plan-then-execute transaction. Later transactions would invalidate and replan. > The fact that we're interested in adding plugin permissions checking > pretty much destroys the idea anyway. You cannot assume that a plan > cache invalidation will happen for any change in external state that > a plugin might be consulting. Plugin can still be executed at appropriate time, its mostly absent and so cheap. I guess we can keep plugin whatever else I attempt. > > The proposed performance enhancement would be very useful since we > have > > to check permissions of functions, views, tables and every other > aspect. > > We could spend a while quantifying that overhead, though "non-zero" > is > > all we need to know. > > No, it's not all we need to know. If you can't prove the overhead > involved here is significant, we should not be expending effort and > creating subtle behavioral changes in pursuit of a minor optimization. OK, will gather evidence. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
