alamb opened a new issue, #7322:
URL: https://github.com/apache/arrow-datafusion/issues/7322

   ### Is your feature request related to a problem or challenge?
   
   This summarizes a discussion @devinjdangelo  and I had here:  
https://github.com/apache/arrow-datafusion/pull/7283#discussion_r1294557588
   
   Basically the API for building a `COPY` statement is likely to get unwieldy 
relatively soon because of all the potential potential options:
   
   
https://github.com/apache/arrow-datafusion/blob/f2c0100a5a10bf3ea166a1a590d94b8c9b6cf673/datafusion/expr/src/logical_plan/builder.rs#L237-L243
   
   Making a config struct  would not only allow additional options to be easily 
added without an API change, it would also provide a natural location to 
document the options and what they meant
   
   Here is an example of such a struct in the DataFrame API:
   
   
https://github.com/apache/arrow-datafusion/blob/f2c0100a5a10bf3ea166a1a590d94b8c9b6cf673/datafusion/core/src/dataframe.rs#L58-L63
   
   And use
   
   
https://github.com/apache/arrow-datafusion/blob/f2c0100a5a10bf3ea166a1a590d94b8c9b6cf673/datafusion/core/src/dataframe.rs#L978-L982
   
   
   ### Describe the solution you'd like
   
   I propose a `CopyOptions` struct such as the following and changing the 
LogicalPlanBuilder::copy to take the struct:
   
   ```rust
   WriteOptions {
     output_url: String,
     file_format: OutputFileFormat, 
     per_thread_output: bool,
     format_specific_options: FormatOptions
   }
   enum FormatOptions {
     Parquet(ParquetWriteOptions), 
   ...
   };
   ```
   
   Along with It might make sense to implement a CopyOptions struct with 
`CopyOptions::from(Vec<String,String>). :
   
   ```rust
   impl From<Vec<String,String>> for WriteOptions {
   ...
   }
   ```
   
    Then, for the `DataFrame::write_*` API the user could construct CopyOptions 
directly rather than passing a `Vec<String,String>` as hey do today which is an 
awkward interface in comparison for use directly from rust code.). 
   
   
   
   
   ### Describe alternatives you've considered
   
   _No response_
   
   ### Additional context
   
   _No response_


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to