Re: dblink - custom datatypes don't work

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?

I think a signature would be very difficult to maintain, it would have
to be consistent for
a datatype (across platforms, and versions of PostgreSQL) while it's
semantics remained
the same, and also be universally unique - central registry etc., urgghh :p

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 :)

Anyway, I'm off to hack around in dblink.c, it's the first time I've
tried SPI,
should be fun! Thanks for your help.

Cheers

--
Mark Gibson <gibsonm |AT| cromwell |DOT| co |DOT| uk>
Web Developer & Database Admin
Cromwell Tools Ltd.
Leicester, England.