Re: IMPORT FOREIGN SCHEMA statement

On Thu, Jul 10, 2014 at 2:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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.
>

Agreed. Modifying postgres_fdw portion to do so would not take long.

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?
>
The SQL-MED spec talks only about foreign tables when importing, It would
be good to keep the checks on CreateTableForeignStmt after parsing the
strings, which is what I imagine server would do after taking back the list
of strings from FDW before creating the objects.

Regards,
--
Michael