[13.x] fix(postgres): whereDate and whereTime crash when $column is an Expression#60305
Closed
ahawlitschek wants to merge 1 commit into
Closed
[13.x] fix(postgres): whereDate and whereTime crash when $column is an Expression#60305ahawlitschek wants to merge 1 commit into
whereDate and whereTime crash when $column is an Expression#60305ahawlitschek wants to merge 1 commit into
Conversation
The `->whereDate` and `->whereTime` functions are typed to accept `Expression` or string as first parameter (`$column`). Since Laravel 12, both underlying functions in `PostgresGrammar` checks whether the `$column` is a JSON selector using the `isJsonSelector($value)` function defined in the base grammar. This function uses `str_contains` and causes a runtime exception if it receives something other than string. Currently, the function is called with the origin value of the `$column` parameter which in some cases may be `Expression`. This adds an `is_string` check to only call `isJsonSelector` if the type of the column is a string and also adds tests which check, that using `Expression` in `whereDate` and `whereTime` produces proper SQL. I discussed several ways to fix this with my colleagues. Swapping `$this->isJsonSelector($where['column'])` with `$this->isJsonSelector($column)` would also fix it. But in my opinion an `Expression` is semantically no json selector and the developer is responsible for ensuring a valid query if `DB::raw()` is used. Changing `isJsonSelector` to also handle `Expression` seems too broad. Another approach would be to always add parentheses within the return statement, since the parentheses are necessary because of the cast. But then more tests need to be adjusted and the created SQL will contain unnecessary parentheses most of the time.
Member
|
Technically a breaking change for |
Contributor
Author
|
Understood. I would still want to fix this bug in a way that's mergable. Under this circumstances the other way I mentioned in my PR description would be suitable. 
When we look at the current implementation in the I adjusted the PR Description, changed the code to the way described above and added tests, that checks also for |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fix:
whereDateandwhereTimecrash when $column is anExpressionThe
->whereDateand->whereTimefunctions are typed to acceptExpressionor string as first parameter ($column). Since Laravel 12, both underlying functions inPostgresGrammarchecks whether the$columnis a JSON selector using theisJsonSelector($value)function defined in the base grammar. This function usesstr_containsand causes a runtime exception if it receives something other than string. Currently, the function is called with the origin value of the$columnparameter which in some cases may beExpression.This changes the parameter from the
isJsonSelectorto the wrapped column instead of the original one. It also adds tests which check, that usingExpressionorStringableinwhereDateandwhereTimeproduces proper SQL.