On Mon, Jun 16, 2014 at 11:28 AM, Michael Paquier <michael.paqu...@gmail.com > wrote:
> On Mon, May 26, 2014 at 6:23 AM, Ronan Dunklau <ronan.dunk...@dalibo.com> > wrote: > > Le dimanche 25 mai 2014 12:41:18 David Fetter a écrit : > >> On Fri, May 23, 2014 at 10:08:06PM +0200, Ronan Dunklau wrote: > >> > Hello, > >> > > >> > Since my last proposal didn't get any strong rebuttal, please find > >> > attached a more complete version of the IMPORT FOREIGN SCHEMA > statement. > >> > >> Thanks! > >> > >> Please to send future patches to this thread so people can track them > >> in their mail. > > > > I'll do. > > > > I didn't for the previous one because it was a few months ago, and no > patch > > had been added to the commit fest. > > > >> > >> > I tried to follow the SQL-MED specification as closely as possible. > >> > > >> > This adds discoverability to foreign servers. The structure of the > >> > statement as I understand it is simple enough: > >> > > >> > IMPORT FOREIGN SCHEMA remote_schema FROM SERVER some_server [ (LIMIT > TO | > >> > EXCEPT) table_list ] INTO local_schema. > >> > > >> > The import_foreign_schema patch adds the infrastructure, and a new FDW > >> > routine: > >> > > >> > typedef List *(*ImportForeignSchema_function) (ForeignServer *server, > >> > ImportForeignSchemaStmt * parsetree); > >> > > >> > This routine must return a list of CreateForeignTableStmt mirroring > >> > whatever tables were found on the remote side, which will then be > >> > executed. > >> > > >> > The import_foreign_schema_postgres_fdw patch proposes an > implementation of > >> > this API for postgres_fdw. It will import a foreign schema using the > right > >> > types as well as nullable information. > >> > >> In the case of PostgreSQL, "the right types" are obvious until there's > >> a user-defined one. What do you plan to do in that case ? > >> > > > > The current implementation fetches the types as regtype, and when > receiving a > > custom type, two things can happen: > > > > - the type is defined locally: everything will work as expected > > - the type is not defined locally: the conversion function will fail, > and > > raise an error of the form: ERROR: type "schema.typname" does not exist > > Just wondering: what about the case where the same data type is > defined on both local and remote, but with *different* definitions? Is > it the responsibility of the fdw to check for type incompatibilities? > Logically, should be. Just wondering, cant we extend the above proposed function typedef List *(*ImportForeignSchema_function) (ForeignServer *server, ImportForeignSchemaStmt * parsetree); be changed a bit to give exact type definitions from the remote side as well? Regards, Atri Regards, Atri *l'apprenant*
