On 2015-08-25 14:42:32 -0400, Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
