Re: [GENERAL] dblink - custom datatypes don't work

[ moving to HACKERS ]

Mark Gibson wrote:
> Joe Conway wrote:
>> Mark Gibson wrote:
>>> [custom datatype oid mismatch between local and remote side of
>>> dblink ]
>>
>> 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.
>>
> But matching datatypes by name would surely be safer than matching by
> oid - it's not impossible that different datatypes on each side of
> the dblink share the same oid. Infact, would it not be more likely
> that two datatypes with the same name are actually the same datatype,
> than two types with the same oid, not counting internal types. But
> then again, are internal types guaranteed to share the same oid
> between PostgreSQL versions?

Sounds reasonable -- any other thoughts out there?

The extra SPI lookup does add cost to every use of the function though.
We'd want to figure out how to cache the results of the lookup.

> Could a config option be added somewhere to switch between oid and
> name matching. With name matching it could be a policy of dblink
> usage that datatype names must remain consistent between db's - but I
> think this would generally be a good thing away :)

I'd be inclined to say that if matching on type name is thought to be
better, we ought to just go that way wholesale.

Joe