Should Tables.dictrowtable support Tables.columnnames?

[bkamins]

@quinnj Current behavior is:

julia> Tables.columnnames(Tables.dictrowtable([(a=1, b=2), (a=3, b=4), (a=5, b=6)]))
(:names, :types, :values)

[ablaom]

I guess the API does not make any promise about Tables.columnnames(X) for X as above because columnaccess(X) == false, right?

But this behaviour will likely catch users by surprise and I don't see any harm in returning X.names instead.

[bkamins]

Yes, API does not guarantee that Tables.columnnames would work here, but as you say - the returned value is surprising.
In general, the issue is that Tables.columnnames has a default fallback that does not check if passed object follows the contract specified by the API.

In particular the lines:

https://github.com/JuliaData/Tables.jl/blob/main/src/fallbacks.jl#L283
and
https://github.com/JuliaData/Tables.jl/blob/main/src/fallbacks.jl#L286

IMO follow the contract, but I mistakenly wanted to use Tables.columnnames for other tables (like Tables.dictrowtable) and it did not work correctly. That is why I have opened this issue.

[quinnj]

Hmmmm, I don't love the idea of defining columnnames for DictRowTable because then if people start relying on it, they'll wonder why other row tables don't also support it? I'd be in favor of adding a definition like columnnames(::DictRowTable) = error(...) so it's explicit that it doesn't support it vs. getting the confusing return value you mentioned before.

[bkamins]

I think that what is confusing users (and me) is that in the docs it says that Tables.columnnames is required for Tables.AbstractRow and Tables.AbstractColumns, but at the same it is also defined for SOME other types, that are not subtypes of these two, as we can see by calling methods(Tables.columnnames).

So this creates a confusion should this Tables.columnnames usage be restricted only to Tables.AbstractRow and Tables.AbstractColumns or actually it is OK to call it on any object and what it would mean then.

Adding an error for DictRowTable seems OK, but I think that first we need to clarify what are the cases of allowed usage of Tables.columnnames and clearly document it.