Re: IMPORT FOREIGN SCHEMA statement

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> With that, I am marking this patch as ready for committer.

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. This seems like it'd be more robust and in most cases not
any harder for the FDW to generate; moreover, it would greatly improve
the quality of error reporting anytime there was anything wrong with
what the FDW did.

As against that, you could point out that we make FDWs deal with
parsetrees when doing planning. But the important difference there
is that they're mostly *reading* the parsetrees, not building new
ones from scratch, so there's much less opportunity for errors of
omission.

Comments?

regards, tom lane