On 2016/05/02 22:06, Robert Haas wrote:
> On Thu, Apr 28, 2016 at 7:59 AM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp> wrote:
>> On 2016/03/14 17:56, Ashutosh Bapat wrote:
>>> On Mon, Mar 14, 2016 at 1:29 PM, Etsuro Fujita
>>> <fujita.etsuro@lab.ntt.co.jp <mailto:fujita.etsuro@lab.ntt.co.jp>> wrote:
>>> /*
>>> * Build the fdw_private list that will be available to the
>>> executor.
>>> * Items in the list must match order in enum
>>> FdwScanPrivateIndex.
>>> */
>>> fdw_private = list_make4(makeString(sql.data),
>>> retrieved_attrs,
>>> makeInteger(fpinfo->fetch_size),
>>> makeInteger(foreignrel->umid));
>>>
>>> I don't think it's correct to use makeInteger for the foreignrel's
>>> umid.
>>> As long as we are using makeInteger() and inVal() pair to set and
>>> extract the values, it should be fine.
>> Yeah, but my concern about this is eg, print plan if debugging (ie,
>> debug_print_plan=on); the umid OID will be printed with the %ld specifier,
>> so in some platform, the OID might be printed wrongly. Maybe I'm missing
>> something, though.
> That seems like a legitimate, if minor, complaint.
Here is a patch to fix this. That is basically the same as in [1], but
I rebased the patch against HEAD and removed list_make5 and its friends,
which were added just for the postgres_fdw DML pushdown.
Sorry for the delay. I was on vacation.
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/56E66F61.3070201@lab.ntt.co.jp