GitHub user paleolimbot added a comment to the discussion: Proposal: ADBC file drivers with pluggable storage
The extra interfaces are not needed to get started, though: you can implement any file driver today, it just might be more bloated than you'd like because you need a SQL parser and to inline all of your storage backends. Similarly, one can implement a storage abstraction as an ADBC driver today, although you have to invent an options convention and be content with blocking IO until the async stream support lands. To get all of these to talk to each other, I think the only spec change is piping through the driver manager as David sugested (e.g., a callable a driver can use to load another driver). GDAL's callable is here: https://github.com/OSGeo/gdal/blob/13310f750da0a09bbc944067b7d7fa8b8b27b110/gcore/gdal_adbc.h#L35-L38 . It's a good point that this is asking a lot of ADBC; however, it's a very useful concept and ADBC already has 90% of the required interface. Probably forcing implementors of this type of driver to squeeze their drivers into the existing framework is a good way to minimize the maintenance burden until it catches on? GitHub link: https://github.com/apache/arrow-adbc/discussions/4877#discussioncomment-18914812 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
