Re: Reworks of CustomScan serialization/deserialization

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reworks of CustomScan serialization/deserialization
Date: 2016-03-29 01:53:33
Message-ID: CA+TgmoZJP_L1t2PcySWufSqXm7eO3zTLR3ixAVueN5eCmVT0xw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-03-29 01:56:35 Re: Relation extension scalability
Previous Message Robert Haas 2016-03-29 01:52:05 Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat