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? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers