How will you actually grok the schema without Avro?
That's the question, isn't it?
What I want to avoid is a special query type (i.e. anything not "SELECT") because it makes the language less orthogonal because of implementation details that are subject to change (in an ideal world, we'd move away from avro and store schema information in "real" columns, with indexes so you could easily say "give me all the columns for CF X at schema version Y.")
You'd also be limited to basically an RPC style call – no specifying which columns to select, or which rows you're interested in. Not without reinventing that wheel on a LOT of code (because SELECT right now relies on CFS to perform the actual queries).
My first stab was to create a class of "virtual" CFs that would contain read-only data for this kind of query. (Attached.) I stopped when I got to a chicken/egg problem: the natural place to update this view CF is DD.setTableDefinition, but that gets called on startup when Table/CFS objects aren't live yet.
Trying to fake this at the QueryProcessor layer is also unsatisfactory – we come back to the same kind of limitations we'd have with a special-case query type, that we don't have full SELECT support on non-CFS objects without insane amounts of work.
Starting to think that we'll have to bite the bullet and get rid of avro schema serialization to do this right. Which I do think is doable, but it's more than I want to bite off right now. (Until then, clients like JDBC DatabaseMetadata can continue to use the thrift describe_ calls.)