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.dunklau@dalibo.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.
