What feature or improvement would you like to see?
One of the only innovations in ADO.NET versus other database connectivity APIs is that it supports an extensible collection of metadata results. So instead of needing separate APIs for "tables", "views", "procedures", "functions", etc., there's just a single GetSchema which is parameterized by a collection name and a filter collection. There's also a meta-collection named "MetaDataCollections" which returns the list of supported collections, and for each collection it also returns the list of supported filters or properties for that collection.
Without yet specifying exactly how this would look for ADBC, I propose adopting this approach for any new metadata APIs we add. Its primary advantage is that we can add new standard metadata definitions without having to revise the C API.
What feature or improvement would you like to see?
One of the only innovations in ADO.NET versus other database connectivity APIs is that it supports an extensible collection of metadata results. So instead of needing separate APIs for "tables", "views", "procedures", "functions", etc., there's just a single
GetSchemawhich is parameterized by a collection name and a filter collection. There's also a meta-collection named "MetaDataCollections" which returns the list of supported collections, and for each collection it also returns the list of supported filters or properties for that collection.Without yet specifying exactly how this would look for ADBC, I propose adopting this approach for any new metadata APIs we add. Its primary advantage is that we can add new standard metadata definitions without having to revise the C API.