On Fri, 2010-07-09 at 17:21 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Fri, 2010-07-09 at 14:01 -0400, Tom Lane wrote:
> >> Consider PREPARE followed only later by EXECUTE. Your proposal would
> >> make the PREPARE fail outright, when it currently does not.
>
> > Just to avoid wasted investigation: are you saying that is important
> > behaviour that is essential we retain in PostgreSQL, or will you hear
> > evidence that supporting that leads to a performance decrease elsewhere?
>
> Well, I think that that problem makes moving the checks into the planner
> a nonstarter. But as somebody pointed out upthread, you could still get
> what you want by keeping a flag saying "permission checks have been
> done" so the executor could skip the checks on executions after the
> first.
Seems like best idea.
> I'd still want to see some evidence showing that it's worth
> troubling over though. Premature optimization being the root of all
> evil, and all that. (In this case, the hazard we expose ourselves to
> seems to be security holes due to missed resets of the flag.)
If we did this it would be to add one line to the code
if (!perms_ok)
That doesn't seem to fall into the category of evil optimization to me.
I've seen you recode other parts of the executor stating reasons like
"shave another few cycles off the main path" and that seems the case
here. We shouldn't need to debate the consequences of Amhdahls law each
time.
Attached is a script to allow pgbench to be used to measure difference
between superuser and a typical privilege model for the pgbench tables.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services