These two clauses have nearly identical semantics with regards to how they would be constructed as an AST. It doesn't make sense for their interfaces to be separate.
Arel 7.0 dropped support for 1.9 (see f1a3421). We should remove jruby (1.7.18) which only supports 1.9 and test the latest jruby head (126.96.36.199.pre1). After jruby 9k has been released (and Travis has updated) we can safely switch back to jruby.
This will allow most consuming code to avoid the deprecation introduced in 008445d. The only code which will be affected is code that is building the `Arel::Table` object manually, rather than calling `arel_table` on an Active Record class. Hopefully this case will be rare enough that we don't need to introduce any additional APIs to work around it.
Rails now performs all casting eagerly, before passing the value into Arel. Once we remove this, the code on both sides will be simplified greatly. Ideally, we can provide the appropriate public APIs on the Rails side to ease this transition for library authors who depend on this behavior.
to_SQL already has supported the ESCAPE clause in #318. PostgreSQL can use the ESCAPE clause too.
We need to be able to not care which we've gotten in ActiveRecord
We're going to start working on removing type casting from arel. To avoid doing one gigantic commit which moves everything over to eager casting, we need a way to tell Arel that we've already cast it. The easiest path to that is to give it a quoted node, and then we remove this case once we're never returning a Casted node
It is never used outside of convenience methods which are only used in tests. In practice, it just made constructing tables more complicated on the rails side. This is the minimum possible change to remove the constructor argument, but continue to have the tests passing. I'm not sure if we have a reason to keep `project` and friends, and the solution might actually just be to remove the engine from `SelectManager` and friends. As such I've held off on deleting those methods. We need to figure out what to do with `Table#from`. It's old invocation, which read `table.from(table)` was certainly nonsensical.
The only place this method was still used is on the MSSQL visitor. The visitor has all of the objects required to inline this lookup there. Since the `primary_key` method on the connection adapter will perform a query when called, we can cache the result on the visitor.
The only reason we're using strings is to pre-populate the cache, but `Class#name` returns a new string instance on every call. This is a pretty major source of memory usage. We don't technically need to pre-populate the cache, and not doing so allows us to go back to using cache objects
This removes the need for us to do the re-ordering by walking the AST in ActiveRecord. We're using a block to communicate with the collector, since the collector needs to be the thing which knows about the index, while the visitor is the thing that needs to know the syntax. The BindParam needs to know about neither of these things, so it's been changed to stop being a subclass of SqlLiteral I could also see an alternative implementation using format strings if for some reason blocks cause a problem.