Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)

On Fri, Mar 4, 2016 at 2:37 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2016-02-12 15:56:45 +0100, Andres Freund wrote:
>> Hi,
>>
>>
>> On 2016-02-10 23:26:20 -0500, Robert Haas wrote:
>> > I think the part about whacking around the FDW API is a little more
>> > potentially objectionable to others, so I want to hold off doing that
>> > unless a few more people chime in with +1. Perhaps we could start a
>> > new thread to talk about that specific idea. This is useful even
>> > without that, though.
>>
>> FWIW, I can delete a couple hundred lines of code from citusdb thanks to
>> this...
>
> And I'm now working on doing that.
>
>
>> why exactly did you expose read/writeBitmapset(), and nothing else?
>> Afaics a lot of the other read routines are also pretty necessary from
>> the outside?
>
> I'd like to also expose at least outDatum()/readDatum() - they're not
> entirely trivial, so it'd be sad to copy them.
>
>
> What I'm wondering about right now is how an extensible node should
> implement the equivalent of
> #define WRITE_NODE_FIELD(fldname) \
> (appendStringInfo(str, " :" CppAsString(fldname) " "), \
> _outNode(str, node->fldname))
>
> given that _outNode isn't public, that seems to imply having to do
> something like
>
> #define WRITE_NODE_FIELD(fldname) \
> (appendStringInfo(str, " :" CppAsString(fldname) " "), \
> appendStringInfo(str, nodeToString(node->fldname)))
>
> i.e. essentially doubling memory overhead. Istm we should make
> outNode() externally visible?

I suggest that you write a patch to do whatever you think best and
commit it, with the understanding that future API stability isn't
guaranteed if we decide what you picked is not actually for the best.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company