Re: Custom Scans and private data

From: Andres Freund <andres(at)anarazel(dot)de>
To: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Custom Scans and private data
Date: 2015-08-27 10:44:31
Message-ID: 20150827104431.GC15922@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-08-26 23:55:16 +0000, Kouhei Kaigai wrote:
> - _copyCustomScan() needs to allow to allocate larger than sizeof(CustomScan),
> according to the requirement by custom-scan provider.

I think it's somewhat nice to allow larger objects, but I don't think
it's absolutely necessary.

> - We may need to have a utility function to copy the common part.
> It is not preferable to implement by custom-scan provider itself.

I think that could be done by having the CopyCustomScan callback simply
just returning a new node, *without* filling out those fields.

> - For upcoming readfuncs.c support, I don't want to have READ_XXX_FIELD()
> macro on the extension side. Even though pg_strtok() is a public function,
> _readBitmapset() is static function.

Yea, the general copying code for other node types should reusable for
that. Invoke parseNodeString() should be usable.

> - Is custom_private deprecated? Also, do we force to have CopyObjectCustomScan()
> and potentially TextReadCustomScan()?

I'd either remove it, or add a second void * private field which has to
be copied by CopyObjectCustomScan() while leaving the responsibility to
custom_private. I honestly don't see too much value in keeping it.

> It may not be a long future. The ParallelAppend feature, I've discussed
> in another thread, needs capability of plan tree serialization, and under
> the development:

Yes, I skimmed through those discussions.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-08-27 10:52:03 Re: checkpointer continuous flushing
Previous Message Shulgin, Oleksandr 2015-08-27 09:54:08 Re: psql - better support pipe line