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
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 |