schema_tree_node needs a constructor.

[hyperbolic2346]

Nitpick: Looks like schema_tree_node needs a constructor. :]

I would've recommended aggregate initialization, but I'm not sure how appropriate it would be, since it's initializing parent members:

        schema_tree_node col_schema {
          .type            = Type::BYTE_ARRAY,
          .converted_type  = ConvertedType::UNKNOWN,
          .stats_dtype     = statistics_dtype::dtype_byte_array,
          .repetition_type = col_nullable ? OPTIONAL : REQUIRED,
          .name = (schema[parent_idx].name == "list") ? "element" : col_meta.get_name(),
          .parent_idx  = parent_idx,
          .leaf_column = col
        };

My personal preference would be to avoid construct-then-initialize. But this is purely stylistic. Please feel free to ignore.

Originally posted by @mythrocks in #11328 (comment)

[github-actions]

This issue has been labeled inactive-30d due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d if there is no activity in the next 60 days.

[vyasr]

@mythrocks @hyperbolic2346 I looked through the code in writer_impl.cu and I'm not sure what the best approach is here. Aggregate initialization is totally fine with (public) parent classes and members, but the issue with either aggregate initialization or the use of a constructor is that I see at least three variants of these objects in terms of what members are set. It's not clear to me if those are the only options, or if there might even be further combinations of attributes set in future iterations, each of which would necessitate a different constructor signature. With C++20 designated initializers we could do this very neatly, but I don't see a clean solution right now. Am I understanding correctly how the object could be used, or do you think there is a simpler constructor we could define to improve the code in its current state?