Re: Speed dblink using alternate libpq tuple storage - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Speed dblink using alternate libpq tuple storage
Date
Msg-id 20120330.133035.58125839.horiguchi.kyotaro@oss.ntt.co.jp
Whole thread Raw
In response to Re: Speed dblink using alternate libpq tuple storage  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> I've applied a modified form of the conname update patch.  It seemed to
> me that the fault is really in the DBLINK_GET_CONN and
> DBLINK_GET_NAMED_CONN macros, which ought to be responsible for setting
> the surrounding function's conname variable along with conn, rconn, etc.
> There was actually a second error of the same type visible in the dblink
> regression test, which is also fixed by this more general method.

Come to think of it, the patch is mere a verifying touch for the
bug mingled with the other part of the dblink patch to all
appearances. I totally agree with you. It should be dropped for
this time and done another time.

I'am sorry for bothering you by such a damn thing.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Daniel Farina
Date:
Subject: Re: HTTP Frontend? (and a brief thought on materialized views)
Next
From: Dobes Vandermeer
Date:
Subject: Re: HTTP Frontend? (and a brief thought on materialized views)