Opened 8 years ago
Last modified 5 years ago
#39826 new enhancement
LIMIT clause not required in get_options function as there's already a UNIQUE KEY on option_name
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Awaiting Review | Priority: | normal |
| Severity: | normal | Version: | 4.7.2 |
| Component: | Database | Keywords: | 2nd-opinion has-patch |
| Focuses: | Cc: |
Description
The Core get_options (wp-includes/option.php) uses LIMIT 1 to retrieve only a single row for an option.
However, the option_name field already has a UNIQUE KEY in the table schema, so it's impossible for the db to contain or return more than one row for any option_name.
Barring history I'm unaware of (if there used to not be a UNIQUE KEY on this field in the past), it's safe to remove the LIMIT 1 clauses from these queries (there are a few instances in the function.
While LIMIT clauses can sometimes be harmful to performance, in this particular scenario that's not the case. However, it's just superfluous.
Attachments (1)
Change History (4)
This ticket was mentioned in Slack in #core by noisysocks. View the logs.
5 years ago
#3
@
5 years ago
- Keywords has-patch added; needs-patch removed
Contributed a patch, builds nicely against trunk.
There is a good coverage of this by Unit tests in option/option.php.
N.B. However I do not have any knowledge regarding if there is any hstorical reasons for this, so 2nd-opinion still needed.
@arjenlentz we discussed this in a bug scrub today, and it sounds reasonable. Tagging as
2nd-opinionin case there is some history we're not aware of though.