Well that is intentional for the most part. Most arel objects are intended to be dumb structs

A lot of this falls into drawing that line between information that should exist on the AR class, and information that should exist at the connection adapter level. What I'd like to have happen is that Arel never asks for information, but is instead given the information it needs

Yeah, primary key is definitely something I'd be fine with it knowing and that we can easily give it

Right now my current driver is making the attributes api public and moving it up to Active Model

Both of those require the implementation to stop overriding columns and columns_hash, which means separating type casting from columns

That requires removing type casting from arel (done) for the quote case, and changing how bind values are represented for the type_cast case

And that has opened a whole can of worms, and is leading me down a refactoring path that I've been meaning to investigate for a while

Because most of AR cares about them internally, how they're represented, how to add them, etc, and about once every week or two a bug comes up because some part of AR got it wrong and we're losing bound params somewhere

Basically the removal of column from quote and type_cast was to make it clear in the code that the DB adapter was not the right place to handle richer types. I think that's been sufficiently handled at this point, and you make a good point about things like collation, different quoting mechanisms, etc

The issue is if I did where(foo: "bar"), and substitute_at returned nil, the number of bind params supplied to the query would not match up with the number of substitutes (aside from the fact that the value being queried would be lost)

Sorry if that message appeared twice I can't tell if it failed to send the first time