Hello, This is the new version of dblink patch.
- Calling dblink_is_busy prevents row processor from being used.
- some PGresult leak fixed.
- Rebased to current head.
> A hack on top of that hack would be to collect the data into a
> tuplestore that contains all text columns, and then convert to the
> correct rowtype during dblink_get_result, but that seems rather ugly
> and not terribly high-performance.
>
> What I'm currently thinking we should do is just use the old method
> for async queries, and only optimize the synchronous case.
Ok, I agree with you except for performance issue. I give up to use
row processor for async query with dblink_is_busy called.
> I thought for awhile that this might represent a generic deficiency
> in the whole concept of a row processor, but probably it's mostly
> down to dblink's rather bizarre API. It would be unusual I think for
> people to want a row processor that couldn't know what to do until
> after the entire query result is received.
I hope so. Thank you.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center