Re: Reworks of CustomScan serialization/deserialization

On Mon, Mar 28, 2016 at 11:00 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
>> -----Original Message-----
>> From: pgsql-hackers-owner(at)postgresql(dot)org
>> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Robert Haas
>> Sent: Tuesday, March 29, 2016 10:54 AM
>> To: Kaigai Kouhei(海外 浩平)
>> Cc: Petr Jelinek; pgsql-hackers(at)postgresql(dot)org
>> Subject: Re: [HACKERS] Reworks of CustomScan serialization/deserialization
>>
>> On Mon, Mar 28, 2016 at 9:36 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
>> > I don't have a strong reason to keep these stuff in separate files.
>> > Both stuffs covers similar features and amount of code are enough small.
>> > So, the attached v4 just merged custom-node.[ch] stuff into extensible.
>> >
>> > Once we put similar routines closely, it may be better to consolidate
>> > these routines.
>> > As long as EXTNODENAME_MAX_LEN == CUSTOM_NAME_MAX_LEN, both features
>> > have identical structure layout, so it is easy to call an internal
>> > common function to register or find out a table of callbacks according
>> > to the function actually called by other modules.
>> >
>> > I'm inclined to think to replace EXTNODENAME_MAX_LEN and
>> > CUSTOM_NAME_MAX_LEN by NAMEDATALEN again, to fit structure layout.
>>
>> I don't think that we need both EXTNODENAME_MAX_LEN and
>> CUSTOM_NAME_MAX_LEN; we can use EXTNODENAME_MAX_LEN for both. I'm
>> opposed to using NAMEDATALEN for anything unrelated to the size of a
>> Name. If it's not being stored in a catalog, it doesn't need to care.
>>
> OK, I adjusted the v4 patch to use EXTNODENAME_MAX_LEN for both.
>
> The structure of hash entry was revised as follows, then registered via
> an internal common function: RegisterExtensibleNodeEntry, and found out
> via also an internal common function: GetExtensibleNodeEntry.
>
> typedef struct
> {
> char extnodename[EXTNODENAME_MAX_LEN];
> const void *extnodemethods;
> } ExtensibleNodeEntry;
>
> ExtensibleNodeMethods and CustomScanMethods shall be stored in
> 'extensible_node_methods' and 'custom_scan_methods' separatedly.
> The entrypoint functions calls above internal common functions with
> appropriate HTAB variable.
>
> It will be re-usable if we would have further extensible nodes in the
> future versions.

Committed with a bit of wordsmithing.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company