[custom datatype oid mismatch between local and remote side of dblink ]
Is this a limitation of PostgreSQL or dblink? Could dblink use type names instead of oid's? If not, could dblink be adapted to use some kind of remote oid -> local oid mapping table for datatypes?
I would be willing to have a poke around in dblink.c, if someone could confirm my findings and point me in the right direction.
Without actually having tried it, I think you could hack pgresultGetTupleDesc() in dblink.c. Replace the line:
atttypid = PQftype(res, i);
with an SPI based local lookup using attname.
But I'm not sure if it is really a good idea in general to assume that the same name for a datatype in two databases means that they are actually the same datatype. It would be nice if there was a way to register a "signature" of some kind for custom datatypes that would be unique enough to be sure same named types were actually the same.
Joe
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
