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