On Thu, Jul 10, 2014 at 9:52 AM, Tom Lane <tgl@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).