Re: FOREIGN TABLE doc fix

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> But my point is: any FDW code Dave rights now is not going to have
> major dependencies on the planner that will potentially require
> extensive reworking in the future because it won't have any real
> dependencies on the planner at all. It's not like we have an API and
> we're planning to change it: what we have to talk to the planner right
> now is little more than a stub.

No, what we have to talk to the planner right now is "look through all
of src/include/optimizer/ and call whatever you want, and maybe lift
some code out of src/backend/optimizer/ if the function you need isn't
exported". I agree that a lot of basic FDW work can be done without
much of any planner contact, but as soon as you do get interested in
having non-brain-dead planning behavior in your FDW, you're going to be
doing stuff that way. We're going to want to codify it a bit better
than that; but it's not going to be practical to do so until some people
have taken the plunge and written some code on the understanding that
it's probably throwaway code.

regards, tom lane