[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