Re: FOREIGN TABLE doc fix

Right, but I think he needs the "it's not easy, here's the whole
workflow" overview first.

Ross
--
Ross Reedstrom, Ph.D. reedstrm(at)rice(dot)edu
Systems Engineer & Admin, Research Scientist phone: 713-348-6166
Connexions http://cnx.org fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE

On Mon, Jun 13, 2011 at 04:54:13PM +0100, Dave Page wrote:
> On Mon, Jun 13, 2011 at 4:38 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> >
> >
> > On 06/13/2011 10:25 AM, Dave Page 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 :-(
> >>
> >
> > If nobody bothers then there won't be any experience on which to base a
> > stable API. In particular, I think it's crucial that we get working FDWs for
> > MySQL, SQLServer and Oracle ASAP.
>
> Yeah - MySQL is one of the ones I've been hacking on. It's hard to be
> motivated if its going to need a complete rewrite within a year
> though. I'll still have to work on it, as I've committed to giving
> talks on it, but others might not bother to even start.

I think PostgreSQL has a better track record (especially recently) than
most open source projects at supporting the shared incremental creation and
improvement of first-class features. Yes, getting the first cut of FDW
in place was hard: now it's time for users of that feature to take the
leap of faith and write some code. The faith bit is that others _will_
come forward to help with the rewrites necessary to make it work (or
work better) for their use cases.