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
dblink_rowproc_20120405.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
