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