Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> Tom, could you take a look at them?
I started to look at this today. (Apologies for the delay, but I came
back from San Francisco with a nasty head cold, and wasn't really up to
doing anything complicated last week.)
The thing that jumps out at me right away is that the proposed new amapi.h
header has this:
+ #include "nodes/relation.h"
to support declaring amcostestimate_function. This will result in
importing the planner's declarations into pretty much every part of the
executor, because not only is amapi.h #included by a lot of places, but
the proposed patch actually has execnodes.h including it, as well as some
other popular headers. We might as well shove everything into postgres.h
and forget about header modularity altogether.
Probably the least messy way to fix this is to drop that #include and
instead use dummy declarations like "struct PlannerInfo;" and "struct
IndexPath;" here. We could additionally dumb the amcostestimate
declaration down from using "Cost" and "Selectivity" to just saying
"double".
A different line of attack would be to try to divide amapi.h into
"executor" and "planner" parts, but I'm not sure I see how to make that
work. Somewhere you gotta declare the struct of function pointers.
(Note: I realize that there's a precedent in fdwapi.h of including planner
headers into what's otherwise mostly an executor thing. That one's not
quite as destructive to header modularity because it's not used in as many
places as amapi.h will be. But maybe we should rethink that as well.)
Thoughts, better ideas?
regards, tom lane
