From: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
---|---|
To: | Ronan Dunklau <ronan(dot)dunklau(at)dalibo(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: IMPORT FOREIGN SCHEMA statement. |
Date: | 2014-02-21 11:28:22 |
Message-ID: | CAOeZViedtd0RUHCT9u=wR6URvrjTssPG-Py8s9vdzXT+Jxrb7w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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*
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-02-21 11:40:51 | Re: Changeset Extraction v7.6.1 |
Previous Message | Ronan Dunklau | 2014-02-21 11:26:05 | Re: Proposal: IMPORT FOREIGN SCHEMA statement. |