On 2015-08-25 14:42:32 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Since we already have CustomScan->methods, it seems to be rather
> > reasonable to have a CopyCustomScan callback and let it do the copying
> > of the private data if present? Or possibly of the whole node, which'd
> > allow to embed it into a bigger node?
>
> Weren't there rumblings of requiring plan trees to be deserializable/
> reserializable, not just copiable, so that they could be passed to
> background workers?
Yes, I do recall that as well. that's going to require a good bit of
independent stuff - currently there's callbacks as pointers in nodes;
that's obviously not going to fly well across processes. Additionally
custom scan already has a TextOutCustomScan callback, even if it's
currently probably intended for debugging.
I rather doubt that adding out/readfuncs without the ability to do
something about what exactly is read in is going to work well. But I
admit I'm not too sure about it.
> In any case, since this convention already exists for FDWs I'm not
> sure why we should make it different for CustomScan.
I think it was a noticeable mistake in the fdw case, but we already
released with that. We shouldn't make the same mistake twice. Looking at
postgres_fdw and the pg-strom example linked upthread imo pretty clearly
shows how ugly this is. There's also the rather noticeable difference
that we already have callbacks in the node for custom scans (used by
outfuncs), making this rather trivial to add.
Greetings,
Andres Freund
