Re: FOREIGN TABLE doc fix

On Mon, Jun 13, 2011 at 12:38 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Mon, Jun 13, 2011 at 5:29 PM, Christopher Browne <cbbrowne(at)gmail(dot)com> wrote:
>> On Mon, Jun 13, 2011 at 4:08 PM, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
>>> On Mon, Jun 13, 2011 at 3:54 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>
>>>> 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.
>>>
>>> It's a double-edged sword.  If nobody writes anything, because
>>> everyone is afraid to possibly having to change things, nothing will
>>> never need to be changed ;-)
>>
>> It might be that the process of writing the MySQL FDW code would show
>> off things that'll need to get changed.
>>
>> So the breakage might turn out to be Dave's fault!  :-)
>>
>> [Seriously.]
>>
>> We really won't know what needs fixing/improving until nontrivial FDWs
>> get written, and it would be somewhat ironic, but really not hugely
>> surprising, if Dave wound up requesting changes to the underlying API
>> to *properly* support what he writes.
>>
>> There's some degree of irony and amusement to be found here, but
>> nothing that strikes me as disturbing.
>
> Oh, I can imagine that happening; what I would expect though is that
> we make some attempt to retain compatibility to avoid the need for
> total rewrites of FDWs as Tom seems to be expecting.
>
> 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company