Le lundi 16 juin 2014 11:32:38 Atri Sharma a écrit : > On Mon, Jun 16, 2014 at 11:28 AM, Michael Paquier <michael.paqu...@gmail.com > > wrote: > > 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. >
This is akin to what Stephen proposed, to allow IMPORT FOREIGN SCHEMA to also import types. The problem with checking if the type is the same is deciding where to stop. For composite types, sure it should be easy. But what about built-in types ? Or types provided by an extension / a native library ? These could theorically change from one release to another. > 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? I toyed with this idea, but the more I think about it the less I'm sure what the API should look like, should we ever decide to go beyond the standard and import more than tables. Should the proposed function return value be changed to void, letting the FDW execute any DDL statement ? The advantage of returning a list of statement was to make it clear that tables should be imported, and letting the core enforce "INTO local_schema" part of the clause. I would prefer if the API is limited by design to import tables. This limitation can always be bypassed by executing arbitrary statements before returning the list of ImportForeignSchemaStmt*. For the postgres_fdw specific case, we could add two IMPORT options (since it looked like we had a consensus on this): - import_types - check_types Import types would import simple, composite types, issuing the corresponding statements before returning to core. Check types would compare the local and remote definition for composite types. For types installed by an extension, it would check that the local type has also been created by an extension of the same name, installed in the same schema, raising a warning if the local and remote version differ. For built-in types, a warning would be raised if the local and remote versions of PostgreSQL differ. However, I don't know what we should be doing about types located in a different schema. For example, if the remote table s1.t1 has a column of composite type s2.typ1, should we import typ1 in s1 ? In S2, optionnaly creating the non-existing schema ? Raise an error ? Regards, -- Ronan Dunklau http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
