dblink - custom datatypes NOW work :)

From: Mark Gibson <gibsonm(at)cromwell(dot)co(dot)uk>
To: "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joe Conway <mail(at)joeconway(dot)com>
Subject: dblink - custom datatypes NOW work :)
Date: 2004-02-13 09:19:05
Message-ID: 402C9689.2080802@cromwell.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-patches

> Mark Gibson wrote:
>
> I've found that dblink works without the oid map, ie: dblink(... , ...
> , false)
> but returns the error when enabled, ie: dblink(... , ... , true)
>

Hello,
I've found the problem, although I'm still a bit confused by it.

When the call to SPI_finish() at the end of pgresultGetTupleDesc
in my patch is removed, it works fine, custom datatypes and all :)

But I still don't understand why this is. Is this safe?

Also, I was thinking about how we could uniquely identify a database.
Are there any variables we could retreive from the remote db after
connecting to it that could form a consistent unique id for that db?

Is there a way we can determine whether 'pg_type'
in the remote database has been modified?
We could automatically update the oid map in that case.

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message CSN 2004-02-13 09:20:12 Re: update set x=(subquery on same table)
Previous Message CSN 2004-02-13 09:09:20 Re: update set x=(subquery on same table)

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2004-02-13 11:59:38 Re: [PATCHES] log session end - again
Previous Message Dennis Haney 2004-02-13 08:27:31 Re: Proposed Query Planner TODO items

Browse pgsql-patches by date

  From Date Subject
Next Message Mark Cave-Ayland 2004-02-13 11:33:22 Re: ANALYZE patch for review
Previous Message Neil Conway 2004-02-13 07:36:04 Re: temp patch for win32 readdir issue