by I am thinking of tweaking EXPLAIN so that it performs ExecutorStart()
and ExecutorEnd() even when you just do plain EXPLAIN (and not EXPLAIN
ANALYZE). The immediate reason for this is an internal change (details
below) but it would have a couple of user-visible side effects:
1. Permissions checking would occur on the tables referenced in the
query. Right now it's possible for a user to EXPLAIN a query he would
not be allowed to execute, which seems like a bad idea. (For example,
a person could infer something about the statistics of a table he
couldn't read, such as column min or max values, by seeing how the
planner optimizes different queries.)
2. Appropriate locks would be acquired on the tables. This is probably
not an improvement, but I don't think it's unpleasant enough to be worth
worrying about.
Any thoughts or objections?
regards, tom lane
(BTW, the REAL reason I want to do this: as part of the read-only-plans
project I would like to get rid of the planner's present activity of
building lists of SubPlans. They're a pain in the neck to maintain and
aren't useful to the planner itself. The executor can easily build the
lists as part of the PlanState tree during ExecutorStart, since it'll be
groveling over the whole plan tree anyway. The *only* place in the
system that needs this info outside the executor is EXPLAIN --- which
does ExecutorStart anyway if it's the EXPLAIN ANALYZE case. Rather than
writing a bunch of extra code to find the subplans the hard way, I want
to just call ExecutorStart always.)
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command