[wp-trac] [WordPress Trac] #59836: Using the pre_get_table_charset filter ensures wpdb->col_meta never gets populated
WordPress Trac
noreply at wordpress.org
Wed Nov 8 14:04:37 UTC 2023
#59836: Using the pre_get_table_charset filter ensures wpdb->col_meta never gets
populated
--------------------------+-----------------------------
Reporter: c0ntax | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Database | Version: 6.3.3
Severity: normal | Keywords:
Focuses: |
--------------------------+-----------------------------
I have a non-core table with a binary column that I use for selects and
deletes (it's an efficient way to store UUIDs). I've noticed that whenever
I attempt to do select from it, WP does a relatively expensive SHOW FULL
COLUMNS FROM query, which seems to be uncachable. I've been attempting to
use the pre_get_table_charset filter to get around this, but this then
caused problems when get_col_charset() runs in the same call. It seems
that inside get_table_charset() there is the line $this->col_meta[
$tablekey ] = $columns; which appears to be the only place that col_meta
is ever populated. But it wont be populated for that table if you use the
hook, so if something like this then runs:
{{{#!php
// If still no column information, return the table
charset.
if ( empty( $this->col_meta[ $tablekey ] ) ) {
return $this->table_charset[ $tablekey ];
}
}}}
as it does in get_col_charset() then things just break. col_meta for that
table is not populated and neither is table_charset. I'm too stupid to
work out the best way to fix this I'm afraid.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/59836>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list