Pedro Holanda

> > Hi, @wisp3rwind thanks for your PR. Could you please add test cases to the fetch functions you added? > > Sure. I'll extend existing tests that seem relevant,...

> > I would say we can keep `df()` and `fetch_df()`, `numpy()` and `fetch_numpy()` and merge all arrow functions with a flag to output either an arrow table or a...

Hey Jonathan, thank you for your PR and for taking the initial step on consuming arrow through the jdbc. I understand it is experimental and challenging to add tests for...

Yes, there is a very strict policy on what can be a dependency. Arrow is not and should not be a dependency on any API. However, the tests and their...

I think the difference is that the duckdb-wasm uses Arrow as the data protocol for the data import and all query results. So it's intrinsic for the functionality of the...

Hey @jonathanswenson, we recently got out-of-tree extensions working, these extensions allow us to develop them in a separate repository, without limitations on dependencies. Yesterday, I started working on an Arrow...

I think so too, in theory, any of our current extensions could be out-of-tree, and I do think this brings many advantages, as it reduces the necessity of inlining dependencies,...

Moving this issue to: https://github.com/duckdblabs/substrait/issues/3

@Mause what you mean with checking if the protocol is implemented? I think we could support ```MemoryMappedTable``` by making the ```ds.data.table``` call internally

Sorry for my naive question, but how should that be done in practice? Attribute checking on the object? Or maybe there is a cleaner solution?