Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)
От | Robert Haas |
---|---|
Тема | Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c) |
Дата | |
Msg-id | CA+TgmoakXJxwHd1AF4z5fFtLZds1ejLL03YT1zymNxbxwDqYiQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c) (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Ответы |
Re: CustomScan in a larger structure (RE: CustomScan
support on readfuncs.c)
|
Список | pgsql-hackers |
On Mon, Jan 25, 2016 at 8:06 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote: > Sorry for my late response. I've been unavailable to have enough > time to touch code for the last 1.5 month. > > The attached patch is a revised one to handle private data of > foregn/custom scan node more gracefully. > > The overall consensus upthread were: > - A new ExtensibleNodeMethods structure defines a unique name > and a set of callbacks to handle node copy, serialization, > deserialization and equality checks. > - (Foreign|Custom)(Path|Scan|ScanState) are first host of the > ExtensibleNodeMethods, to allow extension to define larger > structure to store its private fields. > - ExtensibleNodeMethods does not support variable length > structure (like a structure with an array on the tail, use > separately allocated array). > - ExtensibleNodeMethods shall be registered on _PG_init() of > extensions. > > The 'pgsql-v9.6-custom-private.v3.patch' is the main part of > this feature. As I pointed out before, it uses dynhash instead > of the self invented hash table. On a first read-through, I see nothing in this patch to which I would want to object except for the fact that the comments and documentation need some work from a native speaker of English. It looks like what we discussed, and I think it's an improvement over what we have now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: