Re: Arguments to foreign tables? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Arguments to foreign tables?
Date
Msg-id 13871.1352217310@sss.pgh.pa.us
Whole thread Raw
In response to Re: Arguments to foreign tables?  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Arguments to foreign tables?
List pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Jeff Davis <pgsql@j-davis.com> writes:
>> Take something as simple as generate_series: right now, it materializes
>> the entire thing if it's in the FROM clause, but it wouldn't need to if
>> it could use the foreign table mechanism.

> So, my understanding of your proposal is that a good way to implement
> streaming SRF would be on top of the internals of Foreign Data Wrappers?

I'm inclined to think that this proposal is at best premature.  The FDW
mechanisms are still very much a work in progress, and I will *not*
promise anybody that we aren't going to change those APIs repeatedly
before all the dust has settled.  As such, I think we'd better confine
the audience to those few souls brave enough to try to write actual
foreign data wrappers.  If we put up signs telling the average Joe to
use those APIs for SRFs, we're going to have a lot of pressure to
preserve the existing APIs, no matter how broken they turn out to be.

I'd also opine that the FDW APIs are pretty darn heavyweight for an SRF.
There might be a small number of SRFs for which it's actually worth
dealing with the planner in full generality, but surely not very many.
        regards, tom lane



pgsql-hackers by date:

Previous
From: John Lumby
Date:
Subject: Re: [PATCH] Prefetch index pages for B-Tree index scans
Next
From: Robert Haas
Date:
Subject: Re: MySQL search query is not executing in Postgres DB