Re: IMPORT FOREIGN SCHEMA statement - Mailing list pgsql-hackers

Le lundi 16 juin 2014 11:32:38 Atri Sharma a écrit :
> On Mon, Jun 16, 2014 at 11:28 AM, Michael Paquier <michael.paquier@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