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.dunk...@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. 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
signature.asc
Description: This is a digitally signed message part.
