From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FOREIGN TABLE doc fix |
Date: | 2011-06-13 18:05:54 |
Message-ID: | BANLkTi==+BQDZRM9-qtVOtj5piB3wvH8tQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 13, 2011 at 6:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Jun 13, 2011 at 12:38 PM, Dave Page <dpage(at)pgadmin(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-06-13 18:08:18 | Re: FOREIGN TABLE doc fix |
Previous Message | Tom Lane | 2011-06-13 17:56:53 | Re: FOREIGN TABLE doc fix |