AbstractIndexedTable{RowType} <: AbstractArray{RowType}

[SimonDanisch]

Is that something we could have? We can fallback to Any if the row type is not clear, but I think there are many cases where the row type can be computed easily.
Background:
I have my own row type, that already works great with the table interface.
In other parts of my code I have functions defined like:

algorithm(::AbstractArray{<: MyRowType})

With the requested change, I could easily make those algorithms work on JuliaDB / IndexedTables etc, without it caring about it ;)

@piever mentioned, that this is how StructArrays works already, and StructArrays is actually used as the underlying container in InexedTables, so that would make the change even easier?!

[joshday]

I tend to prefer avoiding making tables act like arrays and vice versa. Why not rely on the tables interface for algorithm?

If your code already works with StructArrays, you can use rows(tbl) to get a StructArray.

[SimonDanisch]

Hm, I guess I argument goes pretty similar as yours :D
I prefer avoiding writing anything specific to tables and would love to just define my algorithms on AbstractArray{<: Row}, without anyone needing to figure out, that rows(collection) needs to be called before calling the algorithm ;)

[piever]

I'm not aware of the technical advantages/disadvantages of having them be an AbstractArray, but maybe it'd be enough to define a convert(::Type{AbstractArray}, t::IndexedTable) to return the StructArray of rows and you could call convert(::Type{AbstractArray}, t) before running your algorithm? Alternatively something like Tables.rows(t) is your best chance of getting something that works for all table types, even though not all tables implement rows as an AbstractArray: JuliaData/Tables.jl#50.