Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Date
Msg-id CADyhKSXtv1F6kPsakZuCv2Kti1sMAuPf3nqEhEUWMJ4eqZuB2g@mail.gmail.com
Whole thread Raw
In response to Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
List pgsql-hackers
2015-01-10 9:56 GMT+09:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
> On 1/9/15, 6:54 PM, Jim Nasby wrote:
>>
>> On 1/9/15, 6:44 PM, Petr Jelinek wrote:
>>>>>
>>>>>
>>>> Yep, I had a same impression when I looked at the code first time,
>>>> however, it is defined as below. Not a manner of custom-scan itself.
>>>>
>>>> /*
>>>>   * ==========
>>>>   * Scan nodes
>>>>   * ==========
>>>>   */
>>>> typedef struct Scan
>>>> {
>>>>      Plan        plan;
>>>>      Index       scanrelid;      /* relid is index into the range table
>>>> */
>>>> } Scan;
>>>>
>>>
>>> Yeah there are actually several places in the code where "relid" means
>>> index in range table and not oid of relation, it still manages to confuse
>>> me. Nothing this patch can do about that.
>>
>>
>> Well, since it's confused 3 of us now... should we change it (as a
>> separate patch)? I'm willing to do that work but don't want to waste time if
>> it'll just be rejected.
>>
>> Any other examples of this I should fix too?
>
>
> Sorry, to clarify... any other items besides Scan.scanrelid that I should
> fix?
>
This naming is a little bit confusing, however, I don't think it "should" be
changed because this structure has been used for a long time, so reworking
will prevent back-patching when we find bugs around "scanrelid".

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Escaping from blocked send() reprised.
Next
From: Amit Kapila
Date:
Subject: Re: Parallel Seq Scan