[
https://issues.apache.org/jira/browse/ARROW-17503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17583892#comment-17583892
]
Weston Pace commented on ARROW-17503:
-------------------------------------
This seems like it will be tricky. The fetch node is a sink node. The
consumer currently expects sink nodes to come from the caller. I'm not sure of
a great way to work around this.
Brainstorming on a currently meeting-fried brain I might think something like...
* The FromProto for relation returns a current ordering and fetch info
* Note, if FromProto is called and there is already an ordering / fetch info
then it should be an error as Acero can't handle this
* The ordering / fetch info is passed on to the declaration factory in
addition to the other two inputs
* The declaration factories (at least the consuming sink one) is extended so
that, if an ordering / fetch info is present, then it uses the appropriate sink
node.
Maybe ordering / fetch info could be part of declaration info? CC [~bkietz]
> [C++] Adding Fetch Node FromProto
> ---------------------------------
>
> Key: ARROW-17503
> URL: https://issues.apache.org/jira/browse/ARROW-17503
> Project: Apache Arrow
> Issue Type: Sub-task
> Components: C++
> Reporter: Vibhatha Lakmal Abeykoon
> Assignee: Vibhatha Lakmal Abeykoon
> Priority: Major
>
> Serializing FetchNode with Substrait.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
