You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previously, null values in the columns field caused issues during the explode operation. This fix ensures that explode is only called when columns is not null, preventing potential errors, depreaction warnings and improving data consistency.
Background:
When indexes are created with an expression, Indexes on Expressions rather than a table column, php raises a deprecation warning message LOG.warning: explode(): Passing null to parameter #2 ($string) of type string is deprecated in vendor/laravel/framework/src/Illuminate/Database/Query/Processors/PostgresProcessor.php on line 127
This is particularly evident when using indexes based on expressions rather than indexes based on a table column. An example of why you would want to do this might be indexing based upon an aggregation of the year in a timestamp field.
As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.
If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.
Laravel Version
11.35.1
PHP Version
8.3.14
Database Driver & Version
8.3.14
Description
Previously, null values in the
columns
field caused issues during theexplode
operation. This fix ensures thatexplode
is only called whencolumns
is not null, preventing potential errors, depreaction warnings and improving data consistency.Background:
When indexes are created with an expression, Indexes on Expressions rather than a table column, php raises a deprecation warning message
LOG.warning: explode(): Passing null to parameter #2 ($string) of type string is deprecated in vendor/laravel/framework/src/Illuminate/Database/Query/Processors/PostgresProcessor.php on line 127
This is particularly evident when using indexes based on expressions rather than indexes based on a table column. An example of why you would want to do this might be indexing based upon an aggregation of the year in a timestamp field.
Steps To Reproduce
Create a table in a migration with a functional index
Create a call to get indexes
The text was updated successfully, but these errors were encountered: