Re: Proposal: IMPORT FOREIGN SCHEMA statement.

On Fri, Feb 21, 2014 at 4:56 PM, Ronan Dunklau <ronan(dot)dunklau(at)dalibo(dot)com>wrote:

> 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.
>

Yeah, thats what I wondered. Ok, now I get it. The responsibility of FDW
shall suffice for us.

>
> 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.
>

Got that.

>
> > 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.
>

Yes, I understand it now. My concerns are not valid anymore.

Thanks for the detailed description.

Regards,

Atri

--
Regards,

Atri
*l'apprenant*