Re: IMPORT FOREIGN SCHEMA statement

On Thu, Jul 10, 2014 at 9:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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