Add SQL function UPPER to Arel::FactoryMethods

[jdufresne]

This mirrors the LOWER function that already exists.

This SQL function is useful for string fields but also for PostgreSQL range fields where UPPER returns the upper bound of the range.

[simi]

:thinking: To keep it in pair with LOWER it will probably need upper method in Arel::Attributes::Attribute class as well to be able to use it similar to User.arel_table[:id].lower.

https://github.com/rails/rails/blob/76b0ef8d00e3d824c42f3b71319edc15e7aa7a3e/activerecord/lib/arel/attributes/attribute.rb#L18-L20

Anyway since arel is considered (sadly) private API and lower was implemented most likely only because of case insensitive validations (https://github.com/rails/rails/commit/070c9984a50a5d715a8d2cd3847ae4b603a10d19 + https://github.com/rails/arel/commit/30c7f0e4b365c85b7a910a0553ed936be56b9c4b) I'm not sure this change would be welcomed. :thinking:

[jdufresne]

To keep it in pair with LOWER it will probably need upper method in Arel::Attributes::Attribute class as well to be able to use it similar to User.arel_table[:id].lower.

Thanks! I added the upper method to Arel::Attributes::Attribute as well.

Anyway since arel is considered (sadly) private API

If arel is private, what is the expected approach a Rails project should take to safely write SQL? Using string building may result in unquoted columns that collide with keywords or sometimes present cross-database incompatibilities. The safety of arel is why I use it.

[simi]

If arel is private, what is the expected approach a Rails project should take to safely write SQL? Using string building may result in unquoted columns that collide with keywords or sometimes present cross-database incompatibilities. The safety of arel is why I use it.

Feel free to check https://discuss.rubyonrails.org/t/what-has-happened-to-arel/74383/6 for more info. I'm not sure what is currently recommended approach for this, maybe there is none currently.