-
Hartley McGuire authored
Previously, function aliases (ex. combining a `#group` and `#count`) would make queries non-retryable because `Function#as` would always wrap a given alias in a non-retryable `SqlLiteral`. This could be addressed by making `Function#as` behave similarly to `AliasPredication` (retry everything). However, `Function#as` can also just be removed so that `Function` uses `AliasPredication#as` instead. This behaves slightly differently because `AliasPredication#as` will now return the `Function` wrapped in an `Alias` (meaning the return value must be used). Only a single place in Active Record needed to be changed and all others already did the correct thing. This also resolves a long standing FIXME suggesting removing the custom `Function#as` in favor of using `Alias` nodes. The other half of the comment suggesting `Function` could inherit from `Unary` does not make sense because SQL functions could potentially take multiple parameters, so the existing superclass should not be changed.
Hartley McGuire authoredPreviously, function aliases (ex. combining a `#group` and `#count`) would make queries non-retryable because `Function#as` would always wrap a given alias in a non-retryable `SqlLiteral`. This could be addressed by making `Function#as` behave similarly to `AliasPredication` (retry everything). However, `Function#as` can also just be removed so that `Function` uses `AliasPredication#as` instead. This behaves slightly differently because `AliasPredication#as` will now return the `Function` wrapped in an `Alias` (meaning the return value must be used). Only a single place in Active Record needed to be changed and all others already did the correct thing. This also resolves a long standing FIXME suggesting removing the custom `Function#as` in favor of using `Alias` nodes. The other half of the comment suggesting `Function` could inherit from `Unary` does not make sense because SQL functions could potentially take multiple parameters, so the existing superclass should not be changed.
Loading