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.
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
