Flight SQL has no bindings for Python, R, etc. and this would give you bindings, albeit indirectly; also, instead of asking users to choose between different APIs, having Flight SQL under ADBC makes the decision easier - servers implement Flight SQL, clients consume ADBC.
On Fri, Aug 19, 2022, at 17:01, Antoine Pitrou wrote: > I see. What is the point of wrapping Flight SQL in ADBC then? Just for > consistency with other drivers? > > > Le 19/08/2022 à 23:00, David Li a écrit : >> No, sorry: I meant only the API definitions by "C"; everything so far is >> actually implemented in C++. There's no reason we couldn't port the SQLite >> driver to pure C with nanoarrow but I've mostly used it as a testbed and not >> tried to make it a 'real' driver. >> >> On Fri, Aug 19, 2022, at 16:19, Antoine Pitrou wrote: >>> Le 19/08/2022 à 20:09, David Li a écrit : >>>> Since it's been a while, I'd like to give an update. There are also a few >>>> questions I have around distribution. >>>> >>>> Currently: >>>> - Supported in C, Java, and Python. >>>> - For C/Python, there are basic drivers wrapping Flight SQL and SQLite, >>>> with a draft of a libpq (Postgres) driver (using nanoarrow). >>>> - For Java, there are drivers wrapping JDBC and Flight SQL. >>>> - For Python, there's low-level bindings to the C API, and the DBAPI >>>> interface on top of that (+a few extension methods resembling >>>> DuckDB/Turbodbc). >>> >>> Did you wrap Flight SQL in pure C?
