On Tue, Apr 19, 2016 at 12:16 PM, Noah Misch <n...@leadboat.com> wrote: > On Sat, Apr 16, 2016 at 08:59:40AM +0900, Michael Paquier wrote: >> On Fri, Apr 15, 2016 at 9:46 PM, Michael Paquier >> <michael.paqu...@gmail.com> wrote: >> > On Fri, Apr 15, 2016 at 8:25 PM, Etsuro Fujita >> > <fujita.ets...@lab.ntt.co.jp> wrote: >> >> How about doing something similar for PQprepare/PQexecPrepared in >> >> postgresExecForeignInsert, postgresExecForeignUpdate, and >> >> postgresExecForeignDelete? >> > >> > Yes, I hesitated to touch those, but they are good candidates for this >> > new interface, and actually it has proved not to be complicated to >> > plug in the new routines in those code paths. >> > >> >> Also, how about doing that for PQexec in connection.c? >> > >> > Here I disagree, this is not adapted. All the PQexec calls are part of >> > callbacks that are triggered on failures, and we rely on such a >> > callback when issuing PQcancel. do_sql_command runs commands that take >> > a short amount of time, so I think as well that it is fine as-is with >> > PQexec. >> >> Here is a new version. I just recalled that I forgot a PQclear() call >> to clean up results. > > Robert, the deadline to fix this open item expired eleven days ago. The > thread had been seeing regular activity, but it has now been quiet for three > days. Do you have an updated plan for fixing this open item?
Note for Robert: pgfdw_get_result copycats PQexec by discarding all PQresult received except the last one. I think that's fine for the purposes of postgres_fdw, but perhaps you have a different opinion on the matter. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
