Re: dblink - custom datatypes don't work - Mailing list pgsql-general

From Joe Conway
Subject Re: dblink - custom datatypes don't work
Date
Msg-id 40229207.2040006@joeconway.com
Whole thread Raw
In response to dblink - custom datatypes don't work  (Mark Gibson <gibsonm@cromwell.co.uk>)
Responses Re: dblink - custom datatypes don't work  (Mark Gibson <gibsonm@cromwell.co.uk>)
List pgsql-general
Mark Gibson wrote:
> [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



pgsql-general by date:

Previous
From: Joe Conway
Date:
Subject: Re: dblink: rollback transaction
Next
From: Rajesh Kumar Mallah
Date:
Subject: Re: Functions in CHECK constraint not getting dumped before