On Mon, Jun 13, 2011 at 1:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Jun 13, 2011 at 12:38 PM, Dave Page <dp...@pgadmin.org> wrote: >>> BTW; it seems to me this should be documented, as it could really hack >>> off developers. I can't see anything in the docs to imply the API >>> might be radically redesigned. > >> And I'm still unconvinced that it's needed. I think we're going to >> end up adding on things that are missing and maybe replacing things >> that are just stubs, but I don't see why we'd whack it around just for >> fun. > > I think we're talking past each other. The point I'm trying to make is > that there are no defined/documented APIs for most of the planner, and > so any FDW that needs to do nontrivial planning stuff will need to reach > into pieces of the code that we've historically felt free to change as > needed. We can't just suddenly decide that all that code is now locked > down on the grounds that somebody might be touching it. As an example, > assuming that I figure out how to do generalized parameterized inner > plans in 9.2, whether or not the changes required might break somebody's > FDW is simply not going to be a consideration. > > Once we have some idea of exactly which aspects of the planner FDWs are > likely to need to depend on, we can write down some API contracts and > then try to adhere to them. But we don't have those today, and I don't > think it's profitable to try to write them until we have some more > experience with writing nontrivial FDWs. > > In practice this might turn out to be less of a problem than Dave > thinks. We've made plenty of changes in the past that could affect > third-party selectivity functions, and lately we've been adding planner > hooks that likewise are seeing call contexts that change from version to > version; but I've not heard very many complaints about those > instabilities. So maybe the average FDW won't find this to be a big > deal either. What I was reacting to at the start of this sub-thread was > the idea that the remote-postgresql FDW in particular would be > cross-version compatible. That's not an "average" FDW; I think that it > will have enough planner dependencies to be a poster child for these > issues.
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. Unless I miss my guess, the work Dave et al are doing right now is just around making PostgreSQL talk to X, for various values of X. Now, if we expose an API to allow qual pushdown, all of those FDWs will need to be updated if they want to support qual pushdown (and maybe even a little bit, if they don't). But the work of, say, making it possible to translate MySQL tuples into PostgreSQL tuples doesn't seem likely to be wasted. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
