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