The answer to your question is rather obvious. But if you really like ORMs then you likely are hoping your comment serves as some form of revelation to me and this blinds you to the answer.
Either way the answer is this:
All the popular versions of SQL. I mean what else could the answer be? Your question was rhetorical. Trying to expose a flaw.
See the sqlalchemy expression language in sqlalchemy core. It's already very similar to what I'm proposing. It exposes something that is one to one to ansi sql. Then the underlying implementation translates that expression language into different sql languages. This is the key: Underlying implementations of ORMs typically ALREADY handle all versions of SQL languages.
What I'm proposing is a realistic extension of that. Separate APIs for EVERY sql language. You already have separate implementations... thus separate APIs is not such a crazy unrealistic extension of that.
All sql languages have common language primitives, thus an API could have two sets of libraries. One for common primitives and the other for language specific primitives. But that common library can end up being a rabbit hole, so if it's possible to do cleanly... sure, but if not then just seperate APIs for every sql language is fine.
I mean does code really need to be portable across sql databases? I wrote ORM code for postgresql, do I suddenly need that code working with SQLlite? It might be a convenience, but it's not a huge requirement.
People usually switch to ORMs because they want to use in-language primitives for their application of choice. It's jarring and inelegant to switch between SQL and javascript or something like that.
The problem with an ORM is that it's a high level abstraction On top of what is ALREADY a high level abstraction: SQL. ANd it's not even a one to one abstraction... they are very different and this actually adds more complexity when it comes to optimizing SQL.
You optimize SQL with hacks to get it to compile into an efficient query. With an ORM you have to hack the ORM in order to hack the sql in order for it to compile into an efficient query. It's nuts.
The fix for this problem is to not use an ORM. You want to use in language primitives? Make an abstraction that is one to one with SQL. A library that gives primitives that directly represent SQL language primitives. That's what we actually all want. We don't actually want an orm.
> The benefit of consistency in this case would be that your git diffs aren't littered with irrelevant changes because someone prefers one convention and someone else prefers the other.
If you didn't care about consistency you wouldn't be changing others people code to be consistent.
You would make your own change and that relevant change remains inconsistent. That's it.
>Which convention is chosen as the default doesn't usually matter (unless some of the edge-cases raised by the other comments are relevant to you), but what matters is what when you look at a diff it isn't polluted.
Again the diff isn't polluted. It is simply inconsistent. This is different from two people battling over which convention to follow (which is what you are referring to). In the later case, yes you will see diffs where one person attempts to change the convention, in the former case you simply see a diff where the change doesn't follow a convention.