Re: FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 3:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dave Page <dpage(at)pgadmin(dot)org> writes:
>> On Mon, Jun 13, 2011 at 3:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Don't hold your breath.  We'll probably be making enough changes in the
>>> FDW infrastructure (particularly planner support) that making an FDW
>>> work on both 9.1 and 9.2 would be an exercise in frustration, if it's
>>> even possible.
>
>> Oh joy. There's a GSoC student working on 2 non-trivial FDW's right
>> now, and I have a couple I've been working on. If we're going to make
>> the API incompatible to that extent, we might as well not bother :-(
>
> Oh, that's by no means a waste of time --- we need some examples to help
> us figure out where the pain points are.  I'm just saying that the best
> ways to do things will probably change quite a bit as we introduce
> solutions for the pain points.  And I don't intend to be too concerned
> about preserving backwards compatibility at this stage.

No problem with providing feedback on pain points, however we're
trying to write production quality code that can be used by people
sooner rather than later, in my case, in my own time. If^WNow I know
I'm likely to have to rewrite it for 9.2, it's significantly harder to
find any kind of enthusiasm to work on it for 9.1.

I think we need to figure out a way to maintain a certain level of
backwards compatibility that isn't going to require massive rewrites,
or people just won't bother with SQL/MED until they know the API is
stable. I know I realised it would change, but I assumed we would
either add new optional function calls, or implement a v2 interface
whilst continuing to support the v1 interface.

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company