Support function table names in Arel Table

[palkan]

Motivation / Background

Make it possible to select from computed/function table using Arel, or pass arbitrary string as a table name

This makes it possible to use Arel to query against functions, e.g., generate_series in PostgreSQL, or json_each, or whatever.

Detail

My particular use-case was in transforming the following SQL to Arel (for SQLite 3):

# posts:
#   title string
#   tags json (array)
Post.where(
  "EXISTS (SELECT 1 FROM json_each(posts.tags) WHERE value = ?)",
   tag
)

Currently, it's not possible to use computed table sources with Arel::Table due to the @name = name.to_s call.
The workaround is:

arel_table = Post.arel_table
table_name = Arel.sql(Arel::Nodes::NamedFunction.new("json_each", [arel_table[:tags]]).to_sql)
tags_arel = Arel::Table.new("", as: :json_tags)
# We can only overwrite the name value after the table is created
tags_arel.name = table_name

Post.where(tags_arel.project(1).where(tags_arel[:value].in(tags)).exists)

With this patch, we can provide a SqlLiteral (or a custom node) right to the Table constructor:

table_name = Arel.sql("json_each(table.tags)")
tags_arel = Arel::Table.new(table_name, as: :json_tags)


table_name = Arel::Nodes::NamedFunction.new("json_each", [arel_table[:tags]]).to_sql
tags_arel = Arel::Table.new(table_name, as: :json_tags)

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one change. Changes that are unrelated should be opened in separate PRs.
• Commit message has a detailed description of what changed and why. If this PR fixes a related issue include it in the commit message. Ex: [Fix #issue-number]
• Tests are added or updated if you fix a bug or add a feature.
• CHANGELOG files are updated for the changed libraries if there is a behavior change or additional feature. Minor bug fixes and documentation changes should not be included.

[palkan]

To preserve current behavior (covered with tests). Not sure it leaked outside of tests though, but prefer to be defensive here.

[palkan]

I decided to not carry an ast node around and convert it into a SQL literal right here.

Alternatively, I considered updated the SQL visitor (to_sql.rb) and handle nodes in the #quote_table_name method. But that would affect some other nodes, too, so I hesitated.

[benedikt]

The downside of calling .to_sql and wrapping it in a Arel::Nodes::SqlLiteral is that this looses track of potential bind params inside the expression. This might be undesirable, especially because the examples you bring up are function calls with parameters.

By not being able to use bind params, the resulting query will get a different signature for every set of params and can't be as easily reused as a prepared statement.

That being said, I agree that #quote_table_name probably isn't the best place to implement this.

[palkan]

the resulting query will get a different signature for every set of params and can't be as easily reused as a prepared statement.

That's a good point (though in real life I prefer to avoid prepared statements).

Refactored to perform complication within a visitor (to_sql.rb#visit_Arel_Table).

[palkan]

Hey @matthewd @benedikt! Could you please take another look?

[benedikt]

@palkan Looks good to me!

[palkan]

Looking for some feedback for this tiny but useful change /cc @rafaelfranca @matthewd