On Thu, Jul 10, 2014 at 2:30 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paqu...@gmail.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
