On Mon, Jun 13, 2011 at 6: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.

Hmm, I wonder if you're correct (as usual :-p). I thought you were
talking about the API as defined here:
http://www.postgresql.org/docs/9.1/static/fdw-routines.html, not
internal planner stuff. I agree that if I use that (and I have, but
only minimally), it should be on my own head.

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

I've certainly seen similar issues with the debugger plugin for
example - but that's not using a documented API, bar a couple of
hooks.

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

That I can understand - you'll have to forgive me for reading more
into "making an FDW work on both 9.1 and 9.2 would be an exercise in
frustration, if it's even possible." though :-)


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: 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

Reply via email to