On Thu, Jul 10, 2014 at 9:52 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> I wrote: > > I've started looking at this patch. I wonder whether it's really such > > a great idea to expect the FDW to return a list of parsetrees for > > CREATE FOREIGN TABLE commands; that seems like a recipe for breakage > > anytime we change the parsetree representation, say add a field to > > ColumnDef. The alternative I'm thinking about is to have the FDW pass > > back a list of strings, which would be textual CREATE FOREIGN TABLE > > commands. > > Here's a rather-heavily-editorialized draft patch that does it like that. > > This patch takes the viewpoint I espoused nearby of allowing names in > the LIMIT TO clause that aren't present on the remote server. If we > decide we want to hew to the letter of the standard on that, I'd be > inclined to enforce this in the core code, not in individual FDWs as > the submitted patch did. (I didn't much like that implementation > anyway, since it didn't tell you which name it was unhappy about.) > Woah, thanks. I've just been through this patch and it looks great. I guess that this implementation is enough as a first shot, particularly regarding the complexity that default expression import would bring up for postgres_fdw (point raised during the review, but not really discussed afterwards). Regards, -- Michael
