While hacking around the planner, the "callback" mechanism in
query_planner started to feel awkward. It would seem more natural to
split query_planner() into two parts: one function to do all the
pre-processing of the jointree, building equivalence classes etc. And a
second function to generate the Paths.
So where the callers currently do this:
/* set up callback arguments */
qp_extra.foo = ...;
qp_extra.bar = ...;
query_planner(root, qp_callback, &qp_extra);
static void
qp_callback(PlannerInfo *root, void *qp_extra)
{
root->sort_pathkeys = ...;
root->query_pathkeys = ...;
}
This would feel more natural to me:
/* process the jointree, build equivalence classes */
process_jointree(root);
/* set up query_pathkeys */
root->sort_pathkeys = ...;
root->query_pathkeys = ...;
query_planner(root);
Attached is a more full-fledged patch to do that.
The callback was introduced by commit db9f0e1d9a. The commit message
explains the choice to use a callback like this:
> There are several ways in which we could implement that without making
> query_planner itself deal with grouping/sorting features (which are
> supposed to be the province of grouping_planner). I chose to add a
> callback function to query_planner's API; other alternatives would have
> required adding more fields to PlannerInfo, which while not bad in itself
> would create an ABI break for planner-related plugins in the 9.2 release
> series. This still breaks ABI for anything that calls query_planner
> directly, but it seems somewhat unlikely that there are any such plugins.
In v12, we can change the ABI.
- Heikki