Re: Custom Scans and private data - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Custom Scans and private data
Date
Msg-id 20150827104431.GC15922@awork2.anarazel.de
Whole thread Raw
In response to Re: Custom Scans and private data  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
List 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



pgsql-hackers by date:

Previous
From: "Shulgin, Oleksandr"
Date:
Subject: Re: psql - better support pipe line
Next
From: Andres Freund
Date:
Subject: Re: checkpointer continuous flushing