Re: FOREIGN TABLE doc fix

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Shigeru Hanada <hanada(at)metrosystems(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FOREIGN TABLE doc fix
Date: 2011-06-13 15:54:13
Message-ID: BANLkTimCbc1uznOscH1QpGitoo0zAhPCew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-06-13 15:56:37 Re: procpid?
Previous Message David Fetter 2011-06-13 15:41:40 Re: Boolean operators without commutators vs. ALL/ANY