Re: Proposal: IMPORT FOREIGN SCHEMA statement.

Le vendredi 21 février 2014 16:45:20 Atri Sharma a écrit :
> On Fri, Feb 21, 2014 at 4:39 PM, Ronan Dunklau
<ronan(dot)dunklau(at)dalibo(dot)com>wrote:
> > > I havent had a look at the patch yet since I dont have a nice editor
> >
> > right
> >
> > > now, but how do you handle inter operability between datatypes?
> > > Specifically, how do you handle those datatypes which have a different
> >
> > name
> >
> > > from the PostgreSQL name for them and/or are stored in a different
> >
> > manner?
> >
> > Do you mean in general, or for the postgres_fdw specifically ?
> >
> > In general, only valid column types should be accepted in the
> > CreateForeignTableStmt. The CreateForeignTableStmt is passed through
> > DefineRelation, which takes care of looking up the actual data types.
> >
> > For the postgres_fdw POC implementation, this is done by parsing the
> > attributes type from the query result with the regtype input functions.
> > The
> > attribute typmod is injected too.
>
> I actually meant in general. Thanks for the reply.
>
> So please help me understand here. How exactly does CreateForeignTableStmt
> help in type compatibility?

I'm not sure I understand your concern. It doesn't help in type compatibility,
it is still the responsibility of the FDW to convert local types to remote
ones.

The CreateForeignTableStmt defines the column, with their types. It is
executed locally to create a new foreign table according to a remote
description of the table. The only difference with a user-written
CreateForeignTable statement is that the structure is crafted by the FDW
instead of the parser.

> A statement may be valid on a foreign server but may not be compatible.

Do you mean the CreateForeignTableStmt ? It has to be valid locally, or it
won't be executed. It is the FDW responsibility to build this statement in
such a way that it is valid locally.

>
> Regards,
>
> Atri

--
Ronan Dunklau
http://dalibo.com - http://dalibo.org