Alexander Korotkov <a.korot...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers