From: | Marko Kreen <markokr(at)gmail(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | shigeru(dot)hanada(at)gmail(dot)com, mmoncure(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, greg(at)2ndquadrant(dot)com |
Subject: | Re: Speed dblink using alternate libpq tuple storage |
Date: | 2012-02-18 21:00:03 |
Message-ID: | CACMqXCLvpkjb9+c6sqJXitMHvrRCo+yu4q4bQ--0d7L=vw62Yg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Demos/tests of the new API:
https://github.com/markokr/libpq-rowproc-demos
Comments resulting from that:
- PQsetRowProcessorErrMsg() should take const char*
- callback API should be (void *, PGresult *, PQrowValue*)
or void* at the end, but not in the middle
I have not looked yet what needs to be done to get
ErrMsg callable outside of callback, if it requires PGconn,
then we should add PGconn also to callback args.
> On Thu, Feb 16, 2012 at 05:49:34PM +0900, Kyotaro HORIGUCHI wrote:
>> I added the function PQskipRemainingResult() and use it in
>> dblink. This reduces the number of executing try-catch block from
>> the number of rows to one per query in dblink.
I still think we don't need extra skipping function.
Yes, the callback function needs have a flag to know that
rows need to be skip, but for such low-level API it does
not seem to be that hard requirement.
If this really needs to be made easier then getRowProcessor
might be better approach, to allow easy implementation
of generic skipping func for user.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2012-02-18 21:07:14 | Re: pgsql_fdw, FDW for PostgreSQL server |
Previous Message | Rob Wultsch | 2012-02-18 20:57:15 | Re: MySQL search query is not executing in Postgres DB |