Re: FOREIGN TABLE doc fix

Dave Page <dpage(at)pgadmin(dot)org> writes:
> On Mon, Jun 13, 2011 at 3:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

The problem here is not so much that we're going to change APIs as that
we don't *have* APIs, in the sense of something we're committing to not
changing. Until we do, you're pretty much coding on sand. I don't
intend to be bound by some concept of "we can't change the planner
because somebody somewhere might be depending on XYZ in their
first-generation FDW". If you're not willing to adapt, then yes, you
should not be writing FDWs yet. Depending on what your idea of "stable"
is, maybe you shouldn't be writing FDWs ever.

Of course, how much you're affected by all this depends on what you're
doing. Something like file_fdw doesn't really have any intelligent
planning to do, so it's likely that it wouldn't get broken too badly by
any changes in the near future --- though I'd still hope that eventually
we have some cleaner APIs for it to call than what you see in its
estimate_costs() today. But a postgresql FDW will need to get pretty
darn intimate with the planner in order to be any good, and I absolutely
will *not* make any promises that code like that will continue to work
unchanged in future versions. To do so would be tantamount to decreeing
that all progress on the planner stopped dead yesterday.

regards, tom lane