Simon Riggs <si...@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. 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.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
