On 2016/04/19 14:25, Etsuro Fujita wrote:
> On 2016/04/19 13:59, Michael Paquier wrote:
>> But huge objection to that because this fragilizes the current logic
>> postgres_fdw is based on: PQexec returns the last result to caller,
>> I'd rather not break that logic for 9.6 stability's sake.
> IIUC, I think each query submitted by PQexec in postgres_fdw.c contains
> just a single command. Maybe I'm missing something, though.
>> A even better proof of that is the following, which just emulates what
>> your version of pgfdw_get_result is doing when consuming the results.
>> + /* Verify that there are no more results */
>> + res = pgfdw_get_result(fmstate->conn, fmstate->query);
>> + if (res != NULL)
>> + pgfdw_report_error(ERROR, res, fmstate->conn, true,
>> fmstate->query);
>> This could even lead to incorrect errors in the future if multiple
>> queries are combined with those DMLs for a reason or another.
> I'd like to leave such enhancements for future work...
On reflection, I'd like to agree with Michael on that point. As
mentioned by him, we should not lose the future extendability. And I
don't think his version of pgfdw_get_result would damage the robustness
of in-postgres_fdw.c functions using that, which was my concern. Sorry
for the noise.
Attached is an updated version of the patch, which modified Michael's
version of the patch, as I proposed in [1] (see "Other changes:"). I
modified comments for pgfdw_get_result/pgfdw_exec_query also, mainly
because words like "non-blocking mode" there seems confusing (note that
we have PQsetnonbloking).
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/5715B08A.2030404@lab.ntt.co.jp